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:hh...@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:16462487...@87.241.44.202 SIP/2.0 > Via: SIP/2.0/UDP 38.98.115.34:5060;branch=z9hG4bK22981681-bdb335 > To: <sip:1646hhhh...@38.98.115.34> > From: <sip:39347hhhh...@38.98.115.34>;tag=2298168-fdb335 > Call-ID: 4926-0-1232058...@38.98.115.7 > CSeq: 1 INVITE > Contact: <sip:393477135...@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 _______________________________________________ -- 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