Andrea Borghi
2009-Jan-15 23:56 UTC
[asterisk-users] multiple registration to sip trunking provider.
a strange problem of multiple sip registrations and peer selection in sip.conf is calling for your suggestions!! let's examine this scenario: some numbers and passwords hidden with HHHs to protect the guilty :) I have 3 distinct sip subscriptions with cordiaip.net provider in US. For each of these i insert in sip.conf (with peer name differences and relefant number/password differences, of course] ------- register => 1646HHHHH25:HHHHH at soft1.ny.cordiaip.net/1646HHHHH25 [cordiaus1] type=friend secret=HHHHH username=1646HHHHH25 fromuser=1646HHHHH25 fromdomain=soft1.ny.cordiaip.net host=soft1.ny.cordiaip.net call-limit=5 outboundproxy=soft1.ny.cordiaip.net disallow=all allow=gsm allow=alaw allow=ulaw context=DID_cordia insecure=port ------- the sip registrations are OK and all seeems fine, BUT i have difficulties to map the incoming call because * is making mistakes in matching the incoming sip INVITE to the relevant peer. Please note that ALL the peers share the very same host and sip port. When i make a call to one of the subscribed cordia number, in sip debug i get a packes similar to this: -------- <--- SIP read from 38.98.115.34:5060 ---> INVITE sip:16462487925 at 87.241.44.202 SIP/2.0 Via: SIP/2.0/UDP 38.98.115.34:5060;branch=z9hG4bK22981681-bdb335 To: <sip:1646HHHHH25 at 38.98.115.34> From: <sip:39347HHHHH22 at 38.98.115.34>;tag=2298168-fdb335 Call-ID: 4926-0-1232058433 at 38.98.115.7 CSeq: 1 INVITE Contact: <sip:393477135822 at 38.98.115.34:5060;transport=udp> Server: Sansay-SIP/8.0 Max-Forwards: 70 Content-Type: application/sdp Content-Length: 201 v=0 o=Sansay-SPX 11 11 IN IP4 38.98.115.9 s=Session Controller c=IN IP4 38.98.115.9 t=0 0 m=audio 15986 RTP/AVP 0 18 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=ptime:20 -------- please note the From: and To: lines, I receive a From: with the caller CID (my mobile phone, in this case) and a To: with the sip number the call is directed to; this seems OK to me. I have read the chan_sip.c source file and it seems that when * receives this invite, it wals through the list of sip users/peers/friends to search for the correct entry from which cloning the sip parameters for the channel (as moh class, call limits, codecs and such) using the host IP as the key (if type=peer) or the caller number (if type=user) getting the values from the From: header. This seems very strange, because the user part of the From: header is potentially ANY number and the host part (and not the port, because is is always 5060 and there is insecure=port in place) in this scenario is not unique due to the 3 peers definitions. Please keep in mind that if i utilize only one registration i have absolutely no problems and can configure * correctly. The problem presents itself ONLY with multiple peers with multiple registrations to the same host/port. I cannot request cordia to forward me the numbers via an unique sip registration (sip trunking) because it seems that they don't offer this service. (but it may well be that i hadn't asked the right question) Can anyone suggest how to implement a correct sip trunking for this scenario, in which I have the incoming calls of the three registration going in a specific context (not the default, see context=DID_cordia in the peer definitions) and the outgoing calls going out via a specific user (so i can choose at the dialplan level with which number i am presenting myself in outgoing calls) I have spent some days trying various combinations of peers and users definitions, going in all cases to crash on the wall of the algorithm * uses to select the correct peer for the incoming calls.
Klaus Darilion
2009-Jan-16 09:03 UTC
[asterisk-users] multiple registration to sip trunking provider.
I do not know cordiip thus I do not know how these 3 different accounts are signaled to you, but some tips: A SIP peer is always identified by host:port - thus there is at "peer" level no way to differ them. But in the register command you specify the contact to be called, e.g. 1646HHHHH25. Thus, if you use 3 different contacts you should be able to differ the 3 accounts in the incoming context using 3 different dial patterns. regards klaus Andrea Borghi schrieb:> a strange problem of multiple sip registrations and peer selection in > sip.conf is calling for your suggestions!! > > let's examine this scenario: > > some numbers and passwords hidden with HHHs to protect the guilty :) > > I have 3 distinct sip subscriptions with cordiaip.net provider in US. For > each of these i insert in sip.conf (with peer name differences and relefant > number/password differences, of course] > > ------- > register => 1646HHHHH25:HHHHH at soft1.ny.cordiaip.net/1646HHHHH25 > > [cordiaus1] > type=friend > secret=HHHHH > username=1646HHHHH25 > fromuser=1646HHHHH25 > fromdomain=soft1.ny.cordiaip.net > host=soft1.ny.cordiaip.net > call-limit=5 > outboundproxy=soft1.ny.cordiaip.net > disallow=all > allow=gsm > allow=alaw > allow=ulaw > context=DID_cordia > insecure=port > ------- > > the sip registrations are OK and all seeems fine, BUT > i have difficulties to map the incoming call because * is making mistakes in > matching the incoming sip INVITE to the relevant peer. > > Please note that ALL the peers share the very same host and sip port. > > When i make a call to one of the subscribed cordia number, in sip debug i get > a packes similar to this: > > -------- > <--- SIP read from 38.98.115.34:5060 ---> > INVITE sip:16462487925 at 87.241.44.202 SIP/2.0 > Via: SIP/2.0/UDP 38.98.115.34:5060;branch=z9hG4bK22981681-bdb335 > To: <sip:1646HHHHH25 at 38.98.115.34> > From: <sip:39347HHHHH22 at 38.98.115.34>;tag=2298168-fdb335 > Call-ID: 4926-0-1232058433 at 38.98.115.7 > CSeq: 1 INVITE > Contact: <sip:393477135822 at 38.98.115.34:5060;transport=udp> > Server: Sansay-SIP/8.0 > Max-Forwards: 70 > Content-Type: application/sdp > Content-Length: 201 > > v=0 > o=Sansay-SPX 11 11 IN IP4 38.98.115.9 > s=Session Controller > c=IN IP4 38.98.115.9 > t=0 0 > m=audio 15986 RTP/AVP 0 18 > a=rtpmap:0 PCMU/8000 > a=rtpmap:18 G729/8000 > a=fmtp:18 annexb=no > a=ptime:20 > -------- > > please note the From: and To: lines, I receive a From: with the caller CID > (my mobile phone, in this case) and a To: with the sip number the call is > directed to; this seems OK to me. > > I have read the chan_sip.c source file and it seems that > when * receives this invite, it wals through the list of sip > users/peers/friends to search for the correct entry from which cloning the > sip parameters for the channel (as moh class, call limits, codecs and such) > using the host IP as the key (if type=peer) or the caller number (if > type=user) getting the values from the From: header. > > This seems very strange, because the user part of the From: header is > potentially ANY number and the host part (and not the port, because is is > always 5060 and there is insecure=port in place) in this scenario is not > unique due to the 3 peers definitions. > > Please keep in mind that if i utilize only one registration i have absolutely > no problems and can configure * correctly. The problem presents itself ONLY > with multiple peers with multiple registrations to the same host/port. > > I cannot request cordia to forward me the numbers via an unique sip > registration (sip trunking) because it seems that they don't offer this > service. (but it may well be that i hadn't asked the right question) > > Can anyone suggest how to implement a correct sip trunking for this scenario, > in which I have the incoming calls of the three registration going in a > specific context (not the default, see context=DID_cordia in the peer > definitions) and the outgoing calls going out via a specific user (so i can > choose at the dialplan level with which number i am presenting myself in > outgoing calls) > > I have spent some days trying various combinations of peers and users > definitions, going in all cases to crash on the wall of the algorithm * uses > to select the correct peer for the incoming calls. > > _______________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users