[Asterisk-Dev] SIP INVITE vs TO URI

[Sherwood McGowan]

It's because your system is passing 's' as it's number, you have to append
/1XXXYYYZZZZ at the end of your register statement. We come across this a
lot at my company when our customers try to connect asterisk to us. 

Cheers and good luck 

->-----Original Message-----
->From: asterisk-dev-bounces at lists.digium.com 
->[mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of 
->William Lloyd
->Sent: Wednesday, September 14, 2005 2:56 PM
->To: asterisk-dev at lists.digium.com
->Subject: [Asterisk-Dev] SIP INVITE vs TO URI
->
->I'm trying to integrate Asterisk to work with a SIP provider.   
->Outbound calls are not an issue.
->
->It's inbound with DID's I'm looking at.
->
->In sip.conf when I register the provider without an 
->extensions like register => 1XXXYYYZZZZ:password at sip.provider.com:5060
->
->Asterisk registers at the provider with the 's' extension.
->
->the problem comes with the provider and the way they setup 
->the user accounts.  They consider you to only have 1 account, 
->not 2.  So the pilot number of 15145551212 is the only one 
->that it accepts registrations from.
->
->For example say you have 2 DID's with this provider
->15145551212 and
->15145551213
->
->you would register with
->register => 15145551212:password at sip.provider.com:5060
->
->but when there is an incoming call from the provider for 
->15145551213 the provider passes the destination in the TO 
->field of the SIP header not in INVITE.
->
->The provider sends the destination as part of the TO field.  
->In the example the asterisk host is behind NAT.
->
->For example
->INVITE sip:s at 192.168.100.20
->TO: <sip:15145551213 at 69.23.45.200>
->
->or
->
->INVITE sip:s at 192.168.100.20
->TO: <sip:15145551212 at 69.23.45.200>
->
->Both get handled by Asterisk s destination.
->
->I've been looking at the get_destination and 
->handle_request_invite code in chan_sip.c to modify this 
->behavior when the INVITE URI and TO URI do not match.
->
->In a quick read of the SIP RFC's this providers 
->implementation seems to be valid.
->
->How would be the best way to handle this addition in the 
->asterisk code?
->
->Ideally I'd like to approach it in a way that would be 
->accepted back into the base asterisk code.
->
->thought?  suggestions?
->
->-bill
->wlloyd at slap.net
->
->
->_______________________________________________
->Asterisk-Dev mailing list
->Asterisk-Dev at lists.digium.com
->http://lists.digium.com/mailman/listinfo/asterisk-dev
->To UNSUBSCRIBE or update options visit:
->   http://lists.digium.com/mailman/listinfo/asterisk-dev
->