Re: [asterisk-users] SIP Registration and INVITE question
7 apr 2009 kl. 12.08 skrev Steve Davies: > 2009/4/7 Olle E. Johansson : >> > [snip] >> >> The REGISTER request in the RFC was really written for a device. >> The way providers use it for trunks with multiple DIDs is outside >> of the >> RFC and is discussed in relation to the SIPconnect specification in >> the SIP forum. >> >> Some providers solve this by not using the Contact: in the register >> request at all for the calls, instead guessing a URI with the DID >> in the user name part, something that breaks communication >> even more as the Contact might include other hints on call routing >> internally, like line button in a SNOM phone. >> >> I would say that the only way right now is to parse the To: header. >> I started working on some code a while ago that would handle >> this better, but never completed it. We simply registered a random >> string and then replaced it with whatever was sent in the To: header >> (which should be the original destination) before hitting the >> dialplan. >> That code still exists in a branch somewhere and in Pineapple. >> >> This code would also solve the issue with registering multiple >> accounts with one provider. >> /O >> > > Thanks Olle, as always, a useful response :) > > In the meantime, I suspect that the following is the current dialplan > based workaround for calls that come in to 's' because of a default > Registration Contact? Yes, if you don't add an extension at the end of the register= configuration, Asterisk defaults to "s" which really is used all around Asterisk when we don't have a given extension. /O ___ -- 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
Re: [asterisk-users] SIP Registration and INVITE question
2009/4/7 Olle E. Johansson :
>
[snip]
>
> The REGISTER request in the RFC was really written for a device.
> The way providers use it for trunks with multiple DIDs is outside of the
> RFC and is discussed in relation to the SIPconnect specification in
> the SIP forum.
>
> Some providers solve this by not using the Contact: in the register
> request at all for the calls, instead guessing a URI with the DID
> in the user name part, something that breaks communication
> even more as the Contact might include other hints on call routing
> internally, like line button in a SNOM phone.
>
> I would say that the only way right now is to parse the To: header.
> I started working on some code a while ago that would handle
> this better, but never completed it. We simply registered a random
> string and then replaced it with whatever was sent in the To: header
> (which should be the original destination) before hitting the dialplan.
> That code still exists in a branch somewhere and in Pineapple.
>
> This code would also solve the issue with registering multiple
> accounts with one provider.
> /O
>
Thanks Olle, as always, a useful response :)
In the meantime, I suspect that the following is the current dialplan
based workaround for calls that come in to 's' because of a default
Registration Contact?
[default]
exten => s,1,Set(DN=${SIP_HEADER(TO):5})
exten => s,n,Set(DN=${CUT(DN,@,1)})
exten => s,n,GotoIf($["${DN}" = "s"]?:default,${DN},1)
exten => s,n,Hangup()
Comments or improvements anyone?
Thanks again.
Steve
___
-- 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
Re: [asterisk-users] SIP Registration and INVITE question
6 apr 2009 kl. 18.46 skrev Steve Davies: > Thanks for the reply - Perhaps I was not clear. > > On the register=> line, if I set /extension to be /12345, then this > just replaces 's' with 12345, and ALL calls, regardless of their > destination number will be routed on the INVITE line to 12...@x.x.x.x, > and the actual destination is specified in the To: header. > > Not particularly useful, and I'd prefer not to have to go fumbling > through the SIP headers to find what was really dialled :) > > Looking at the SIP RFC, the idea is that you specify a set of "What I > will accept" details with each registration in the Contact: headers, > which is intended to include _multiple_ possible destination > addresses. The Registrar will then only ever send calls addressed to > that list of destinations. Sadly, the RFC authors did not think to > consider private point-to-point links where you can usefully say "send > me anything, you know best". Asterisk "fills" by defaulting to a > single s...@x.x.x.x, where the 's' can be replaced by any single number. > The REGISTER request in the RFC was really written for a device. The way providers use it for trunks with multiple DIDs is outside of the RFC and is discussed in relation to the SIPconnect specification in the SIP forum. Some providers solve this by not using the Contact: in the register request at all for the calls, instead guessing a URI with the DID in the user name part, something that breaks communication even more as the Contact might include other hints on call routing internally, like line button in a SNOM phone. I would say that the only way right now is to parse the To: header. I started working on some code a while ago that would handle this better, but never completed it. We simply registered a random string and then replaced it with whatever was sent in the To: header (which should be the original destination) before hitting the dialplan. That code still exists in a branch somewhere and in Pineapple. This code would also solve the issue with registering multiple accounts with one provider. /O --- * Olle E. Johansson - o...@edvina.net * Asterisk Training http://edvina.net/training/ ___ -- 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
Re: [asterisk-users] SIP Registration and INVITE question
Thanks for the reply - Perhaps I was not clear. On the register=> line, if I set /extension to be /12345, then this just replaces 's' with 12345, and ALL calls, regardless of their destination number will be routed on the INVITE line to 12...@x.x.x.x, and the actual destination is specified in the To: header. Not particularly useful, and I'd prefer not to have to go fumbling through the SIP headers to find what was really dialled :) Looking at the SIP RFC, the idea is that you specify a set of "What I will accept" details with each registration in the Contact: headers, which is intended to include _multiple_ possible destination addresses. The Registrar will then only ever send calls addressed to that list of destinations. Sadly, the RFC authors did not think to consider private point-to-point links where you can usefully say "send me anything, you know best". Asterisk "fills" by defaulting to a single s...@x.x.x.x, where the 's' can be replaced by any single number. Most ITSPs work around this by assuming that they know best, and routing numbers even if they are missing from the registration. The odd exception does not do this. I suspect that the solution will be to register with a /extension of /pedanticitsp, and then have a dialplan which pulls and parses the SIP To: header. Other suggestions are still welcome. Regards, Steve 2009/4/6 Martin : > Have you looked at the syntax of register => keyword ? > > register => [transport://]user[:secret[:authuse...@host[:port][/extension] > ; If no extension is given, the 's' extension is used. > > There you have it ... Contact: > set the extension and you should be fine > > Martin > > On Mon, Apr 6, 2009 at 7:45 AM, Steve Davies wrote: >> I have an ITSP we are trying to work with that has an "Unusual" way of >> working, but that said my understanding of their behaviour is that it >> is fully RFC compliant. Can someone suggest how I might be able to >> interoperate under these circumstances: >> >> We register fine with them, and send the default asterisk Contact: header of: >> Contact: >> >> This then causes ALL calls from the ITSP inbound to us to be addressed: >> >> INVITE sip:s...@x.x.x.x:5060;transport=udp SIP/2.0 >> To: >> [other headers omitted] >> >> In fact, whatever we send in the Contact: header is reflected in the >> INVITE for inbound calls, and the actual number dialled is always >> placed in the To: header. What 99.9% of our ITSPs would send is: >> >> INVITE sip:44123456...@x.x.x.x:5060;transport=udp SIP/2.0 >> To: >> [other headers omitted] >> >> As you can see, the correct destination number is placed into the >> INVITE header AND the To: header, and Asterisk routes it correctly >> based on the INVITE. >> >> My questions: >> >> - Is there a way of telling chan_sip to register with multiple >> Contact: headers in the registration request, so that all of the >> acceptable DDI numbers can be presented to the ITSP (This is what the >> RFC seems to suggest is the "correct" way to operate.) >> >> - Alternatively, has anyone encountered this previously, and perhaps >> created an "s" extension that then digs into the To: header, and >> routes according to that? Examples, workarounds and solutions are all >> welcome! >> >> Help? >> >> Thanks, >> Steve >> >> ___ >> -- 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 > ___ -- 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
Re: [asterisk-users] SIP Registration and INVITE question
Have you looked at the syntax of register => keyword ? register => [transport://]user[:secret[:authuse...@host[:port][/extension] ; If no extension is given, the 's' extension is used. There you have it ... Contact: wrote: > I have an ITSP we are trying to work with that has an "Unusual" way of > working, but that said my understanding of their behaviour is that it > is fully RFC compliant. Can someone suggest how I might be able to > interoperate under these circumstances: > > We register fine with them, and send the default asterisk Contact: header of: > Contact: > > This then causes ALL calls from the ITSP inbound to us to be addressed: > > INVITE sip:s...@x.x.x.x:5060;transport=udp SIP/2.0 > To: > [other headers omitted] > > In fact, whatever we send in the Contact: header is reflected in the > INVITE for inbound calls, and the actual number dialled is always > placed in the To: header. What 99.9% of our ITSPs would send is: > > INVITE sip:44123456...@x.x.x.x:5060;transport=udp SIP/2.0 > To: > [other headers omitted] > > As you can see, the correct destination number is placed into the > INVITE header AND the To: header, and Asterisk routes it correctly > based on the INVITE. > > My questions: > > - Is there a way of telling chan_sip to register with multiple > Contact: headers in the registration request, so that all of the > acceptable DDI numbers can be presented to the ITSP (This is what the > RFC seems to suggest is the "correct" way to operate.) > > - Alternatively, has anyone encountered this previously, and perhaps > created an "s" extension that then digs into the To: header, and > routes according to that? Examples, workarounds and solutions are all > welcome! > > Help? > > Thanks, > Steve > > ___ > -- 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
[asterisk-users] SIP Registration and INVITE question
I have an ITSP we are trying to work with that has an "Unusual" way of working, but that said my understanding of their behaviour is that it is fully RFC compliant. Can someone suggest how I might be able to interoperate under these circumstances: We register fine with them, and send the default asterisk Contact: header of: Contact: This then causes ALL calls from the ITSP inbound to us to be addressed: INVITE sip:s...@x.x.x.x:5060;transport=udp SIP/2.0 To: [other headers omitted] In fact, whatever we send in the Contact: header is reflected in the INVITE for inbound calls, and the actual number dialled is always placed in the To: header. What 99.9% of our ITSPs would send is: INVITE sip:44123456...@x.x.x.x:5060;transport=udp SIP/2.0 To: [other headers omitted] As you can see, the correct destination number is placed into the INVITE header AND the To: header, and Asterisk routes it correctly based on the INVITE. My questions: - Is there a way of telling chan_sip to register with multiple Contact: headers in the registration request, so that all of the acceptable DDI numbers can be presented to the ITSP (This is what the RFC seems to suggest is the "correct" way to operate.) - Alternatively, has anyone encountered this previously, and perhaps created an "s" extension that then digs into the To: header, and routes according to that? Examples, workarounds and solutions are all welcome! Help? Thanks, Steve ___ -- 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
