[asterisk-dev] Asterisk and "305 Use Proxy"

Wolfgang Hottgenroth woho at hottis.de
Thu Sep 14 06:06:13 MST 2006


Hi,


here is the SIP trace of the first INVITE, which will be redirected:

#
U 212.153.111.54:5060 -> 212.153.111.23:5060
INVITE sip:+492319721231 at atest8.eng.emea.uu.net SIP/2.0.
Via: SIP/2.0/UDP 212.153.111.54:5060;branch=z9hG4bK00001810;rport.
From: "496922224525" <sip:+496922224525 at localhost>;tag=as00001576.
To: <sip:+492319721231 at atest8.eng.emea.uu.net>.
Contact: <sip:+496922224525 at 212.153.111.54>.
Call-ID: 00005aef000011b9000007d400006103 at localhost.
CSeq: 102 INVITE.
User-Agent: Asterisk PBX.
Max-Forwards: 70.
Remote-Party-ID: "496922224525"
<sip:+496922224525 at localhost>;privacy=off;screen=no.
Date: Thu, 14 Sep 2006 12:21:46 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY.
Content-Type: application/sdp.
Content-Length: 211.
.
v=0.
o=root 16075 16075 IN IP4 212.153.111.54.
s=session.
c=IN IP4 212.153.111.54.
t=0 0.
m=audio 41556 RTP/AVP 0 3 8.
a=rtpmap:0 PCMU/8000.
a=rtpmap:3 GSM/8000.
a=rtpmap:8 PCMA/8000.
a=silenceSupp:off - - - -.

#
U 212.153.111.23:5060 -> 212.153.111.54:5060
SIP/2.0 305 Use Proxy.
Via: SIP/2.0/UDP 212.153.111.54:5060;branch=z9hG4bK00001810;rport=5060.
From: "496922224525" <sip:+496922224525 at localhost>;tag=as00001576.
To:
<sip:+492319721231 at atest8.eng.emea.uu.net>;tag=1e774eabe4d2489f5932bf5c7ec21846.c855.
Call-ID: 00005aef000011b9000007d400006103 at localhost.
CSeq: 102 INVITE.
Contact: <sip:+492319721231 at 212.153.111.19:5061>.
Server: OpenSer (1.2.0-dev1-notls (sparc64/solaris)).
Content-Length: 0.
Warning: 392 212.153.111.23:5060 "Noisy feedback tells:  pid=9144
req_src_ip=212.153.111.54 req_src_port=5060
in_uri=sip:+492319721231 at atest8.eng.emea.uu.net
out_uri=sip:+492319721231 at atest8.eng.emea.uu.net via_cnt==1".
.

#
U 212.153.111.54:5060 -> 212.153.111.23:5060
ACK sip:+492319721231 at atest8.eng.emea.uu.net SIP/2.0.
Via: SIP/2.0/UDP 212.153.111.54:5060;branch=z9hG4bK00001810;rport.
From: "496922224525" <sip:+496922224525 at localhost>;tag=as00001576.
To:
<sip:+492319721231 at atest8.eng.emea.uu.net>;tag=1e774eabe4d2489f5932bf5c7ec21846.c855.
Contact: <sip:+496922224525 at 212.153.111.54>.
Call-ID: 00005aef000011b9000007d400006103 at localhost.
CSeq: 102 ACK.
User-Agent: Asterisk PBX.
Max-Forwards: 70.
Remote-Party-ID: "496922224525"
<sip:+496922224525 at localhost>;privacy=off;screen=no.
Content-Length: 0.
.


The interesting piece is the Contact header of the 305 response:

Contact: <sip:+492319721231 at 212.153.111.19:5061>

This is according to RFC3261.

After this dialog, asterisk is behaving correctly and sends a second
INVITE to the requests URI:

#
U 212.153.111.54:5060 -> 212.153.111.19:5061
INVITE sip:+492319721231 at 212.153.111.19:5061 SIP/2.0.
Via: SIP/2.0/UDP 212.153.111.54:5060;branch=z9hG4bK0000305e;rport.
From: "496922224525" <sip:+496922224525 at 212.153.111.54>;tag=as00003800.
To: <sip:+492319721231 at 212.153.111.19:5061>.
Contact: <sip:+496922224525 at 212.153.111.54>.
Call-ID: 00001b600000172f000070a800001e95 at 212.153.111.54.
CSeq: 102 INVITE.
User-Agent: Asterisk PBX.
Max-Forwards: 70.
Remote-Party-ID: "496922224525"
<sip:+496922224525 at 212.153.111.54>;privacy=off;screen=no.
Date: Thu, 14 Sep 2006 12:21:46 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY.
Content-Type: application/sdp.
Content-Length: 211.
.
v=0.
o=root 16075 16075 IN IP4 212.153.111.54.
s=session.
c=IN IP4 212.153.111.54.
t=0 0.
m=audio 40102 RTP/AVP 0 3 8.
a=rtpmap:0 PCMU/8000.
a=rtpmap:3 GSM/8000.
a=rtpmap:8 PCMA/8000.
a=silenceSupp:off - - - -.


You see, asterisk is using 5061 as destination port.

But, however, this INVITE is intentionally redirected to:

U 212.153.111.19:5061 -> 212.153.111.54:5060
SIP/2.0 305 Use Proxy.
Via: SIP/2.0/UDP 212.153.111.54:5060;branch=z9hG4bK0000305e;rport=5060.
From: "496922224525" <sip:+496922224525 at 212.153.111.54>;tag=as00003800.
To:
<sip:+492319721231 at 212.153.111.19:5061>;tag=533a2daeca083e02afdcbd4f0d35902d.078c.
Call-ID: 00001b600000172f000070a800001e95 at 212.153.111.54.
CSeq: 102 INVITE.
Contact: <sip:+492319721231 at 212.153.111.23:5062>.
Server: OpenSer (1.2.0-dev1-notls (sparc64/solaris)).
Content-Length: 0.
Warning: 392 212.153.111.19:5061 "Noisy feedback tells:  pid=17054
req_src_ip=212.153.111.54 req_src_port=5060
in_uri=sip:+492319721231 at 212.153.111.19:5061
out_uri=sip:+492319721231 at 212.153.111.19:5061 via_cnt==1".
.

#
U 212.153.111.54:5060 -> 212.153.111.19:5061
ACK sip:+492319721231 at 212.153.111.19:5061 SIP/2.0.
Via: SIP/2.0/UDP 212.153.111.54:5060;branch=z9hG4bK0000305e;rport.
From: "496922224525" <sip:+496922224525 at 212.153.111.54>;tag=as00003800.
To:
<sip:+492319721231 at 212.153.111.19:5061>;tag=533a2daeca083e02afdcbd4f0d35902d.078c.
Contact: <sip:+496922224525 at 212.153.111.54>.
Call-ID: 00001b600000172f000070a800001e95 at 212.153.111.54.
CSeq: 102 ACK.
User-Agent: Asterisk PBX.
Max-Forwards: 70.
Remote-Party-ID: "496922224525"
<sip:+496922224525 at 212.153.111.54>;privacy=off;screen=no.
Content-Length: 0.
.

Again the interesting piece is the Contact header in the 305 response:

Contact: <sip:+492319721231 at 212.153.111.23:5062>


Asterisk sends another request, but using port 5060 instead of the
requested 5062:

#
U 212.153.111.54:5060 -> 212.153.111.23:5060
INVITE sip:+492319721231 at atest8.eng.emea.uu.net SIP/2.0.
Via: SIP/2.0/UDP 212.153.111.54:5060;branch=z9hG4bK00007979;rport.
From: "496922224525" <sip:+496922224525 at localhost>;tag=as00003524.
To: <sip:+492319721231 at atest8.eng.emea.uu.net>.
Contact: <sip:+496922224525 at 212.153.111.54>.
Call-ID: 00005295000048390000745e0000022a at localhost.
CSeq: 102 INVITE.
User-Agent: Asterisk PBX.
Max-Forwards: 70.
Remote-Party-ID: "496922224525"
<sip:+496922224525 at localhost>;privacy=off;screen=no.
Date: Thu, 14 Sep 2006 12:21:46 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY.
Content-Type: application/sdp.
Content-Length: 211.
.
v=0.
o=root 16075 16075 IN IP4 212.153.111.54.
s=session.
c=IN IP4 212.153.111.54.
t=0 0.
m=audio 43150 RTP/AVP 0 3 8.
a=rtpmap:0 PCMU/8000.
a=rtpmap:3 GSM/8000.
a=rtpmap:8 PCMA/8000.
a=silenceSupp:off - - - -.


Don't know whether it ignores the requested port or whether it repeats
the initial request for any reason. However, it uses port 5060 instead
of the requested 5062, although it has behaved correctly for the first
redirect.


Cheers,
Wolfgang



Johansson Olle E wrote:
> >
> > 14 sep 2006 kl. 13.07 skrev Wolfgang Hottgenroth:
> >
>> >> Hi,
>> >>
>> >>
>> >> I'm wondering how to configure asterisk the right way to handle
"305 Use
>> >> Proxy" correctly or whether there is a bug in asterisk in the 305
>> >> handling.
> > Well, it's not a bug, but indeed a missing feature. I haven't seen any
> > equipment
> > out there using it or any bug report asking for support of it.
> >
>> >>
>> >> I've asterisk sitting as registrar and rtp-proxy and so on in front of
>> >> two opensers. These both opensers redirect INVITEs as soon as
their load
>> >> is beyond a configure limit to each other. And they increase the
port to
>> >> use for every redirect.
>> >>
>> >> So, the first INVITE goes to openser 1 on port 5060, which
redirects to
>> >> openser 2 and requests port 5061 to be used in the Contact header (cp.
>> >> RFC 3261, #21.3.4). When this proxy in turn redirects, it requests
port
>> >> 5062.
>> >>
>> >> When asterisk receives the first redirect, it repeats the INVITE
>> >> perfectly using the new URI from the Contact header out of the 305
>> >> response. When it then receives the second redirect, now with port
5062
>> >> in the Contact header, it repeat the INVITE again, using the address
>> >> from the Contact header, but not using the port from the Contact
header,
>> >> instead it uses the default port 5060.
>> >>
>> >>
>> >> Does anyone have a hint for my to configure asterisk to handle this
>> >> situation RFC conform?
>> >>
> > Well, it surprises me that we do anything intelligent with that reply.
> > No, there's no support for this in the SIP channel. I would like to see
> > a SIP trace of this from Asterisk's point of view to estimate what can
> > be done.
> >
> > We have some, although poor, support for 302 redirect, no support
> > for multiple choices or use proxy.
> >
> > /O
> >
> > ---
> > Olle E. Johansson * Asterisk Evangelist, developer * VOOP A/S
> > olle at voop.com
> >
> >
> >
> > _______________________________________________
> > --Bandwidth and Colocation provided by Easynews.com --
> >
> > asterisk-dev mailing list
> > To UNSUBSCRIBE or update options visit:
> >   http://lists.digium.com/mailman/listinfo/asterisk-dev


Johansson Olle E wrote:
> 
> 14 sep 2006 kl. 13.07 skrev Wolfgang Hottgenroth:
> 
>> Hi,
>>
>>
>> I'm wondering how to configure asterisk the right way to handle "305 Use
>> Proxy" correctly or whether there is a bug in asterisk in the 305
>> handling.
> Well, it's not a bug, but indeed a missing feature. I haven't seen any
> equipment
> out there using it or any bug report asking for support of it.
> 
>>
>> I've asterisk sitting as registrar and rtp-proxy and so on in front of
>> two opensers. These both opensers redirect INVITEs as soon as their load
>> is beyond a configure limit to each other. And they increase the port to
>> use for every redirect.
>>
>> So, the first INVITE goes to openser 1 on port 5060, which redirects to
>> openser 2 and requests port 5061 to be used in the Contact header (cp.
>> RFC 3261, #21.3.4). When this proxy in turn redirects, it requests port
>> 5062.
>>
>> When asterisk receives the first redirect, it repeats the INVITE
>> perfectly using the new URI from the Contact header out of the 305
>> response. When it then receives the second redirect, now with port 5062
>> in the Contact header, it repeat the INVITE again, using the address
>> from the Contact header, but not using the port from the Contact header,
>> instead it uses the default port 5060.
>>
>>
>> Does anyone have a hint for my to configure asterisk to handle this
>> situation RFC conform?
>>
> Well, it surprises me that we do anything intelligent with that reply.
> No, there's no support for this in the SIP channel. I would like to see
> a SIP trace of this from Asterisk's point of view to estimate what can
> be done.
> 
> We have some, although poor, support for 302 redirect, no support
> for multiple choices or use proxy.
> 
> /O
> 
> ---
> Olle E. Johansson * Asterisk Evangelist, developer * VOOP A/S
> olle at voop.com
> 
> 
> 
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev



More information about the asterisk-dev mailing list