[Users] how to handle 302-moved temporarily
zm23
zm23 at columbia.edu
Sat Mar 31 23:12:38 CEST 2007
Hi Bogdan,
I do see an ack sent back from the gw, however, when new
invite is sent openser relays it according to lcr rules but then a
302 is sent back to the gateway.
Would it be better to detect and process the 302 message in openser
itself?
Thanks.
--
Packet snippet below.
version: openser 1.1.0-notls (i386/linux)
sip proxy: 1.1.1.1
cisco gw: 2.2.2.2
phone: 3.3.3.3
sip ITSP: 4.4.4.4
302 from proxy to gw
#
U 1.1.1.1:5060 -> 2.2.2.2:5060
SIP/2.0 302 Moved Temporarily.
Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bKFFC11F7D.
From: <sip:2125551212 at 2.2.2.2>;tag=2F5940AC-583.
To: <sip:10562 at 1.1.1.1>;tag=8C24D454-B4128FCF.
CSeq: 101 INVITE.
Call-ID: 3C44A32A-DE0A11DB-A824A09A-38207ACB at 2.2.2.2.
Contact: <sip:9318001234567 at siphost.mydomain.com>.
Record-Route: <sip:1.1.1.1;lr=on;ftag=2F5940AC-583>.
User-Agent: PolycomSoundPointIP-SPIP_601-UA/2.1.0.2708.
Diversion: <sip:10562 at 1.1.1.1>;reason="deflection".
Content-Length: 0.
.
Ack from gw to proxy
#
U 2.2.2.2:5060 -> 1.1.1.1:5060
ACK sip:10562 at 1.1.1.1:5060 SIP/2.0.
Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bKFFC11F7D.
From: <sip:2125551212 at 2.2.2.2>;tag=2F5940AC-583.
To: <sip:10562 at 1.1.1.1>;tag=8C24D454-B4128FCF.
Date: Fri, 30 Mar 2007 15:29:07 GMT.
Call-ID: 3C44A32A-DE0A11DB-A824A09A-38207ACB at 2.2.2.2.
Max-Forwards: 70.
CSeq: 101 ACK.
Allow-Events: telephone-event.
Content-Length: 0.
.
New invite is received and forwarded to ITSP and then 302 is sent
from proxy to cisco gw
#
U 1.1.1.1:5060 -> 2.2.2.2:5060
SIP/2.0 302 Moved Temporarily.
Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bKFFC11F7D.
From: <sip:2125551212 at 2.2.2.2>;tag=2F5940AC-583.
To: <sip:10562 at 1.1.1.1>;tag=8C24D454-B4128FCF.
CSeq: 101 INVITE.
Call-ID: 3C44A32A-DE0A11DB-A824A09A-38207ACB at 2.2.2.2.
Contact: <sip:9318001234567 at siphost.mydomain.com>.
Record-Route: <sip:1.1.1.1;lr=on;ftag=2F5940AC-583>.
User-Agent: PolycomSoundPointIP-SPIP_601-UA/2.1.0.2708.
Diversion: <sip:10562 at 1.1.1.1>;reason="deflection".
Content-Length: 0.
.
I am including more packet info below. Please note that I have
multiple remote-party-id headers in the invite forwarded to the
service provider.
remote-party header is edited as packet is received and has to be
edited again before being relayed. I have not been able to undo the
first edit or remove it altogether. Any suggestion?
++++++++++++++++++++++++++++++++
U 3.3.3.3:8891 -> 1.1.1.1:5060
SIP/2.0 302 Moved Temporarily.
Via: SIP/2.0/UDP 1.1.1.1;branch=z9hG4bKe22b.4c0e7b31.0.
Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bKFFC11F7D.
From: <sip:2125551212 at 2.2.2.2>;tag=2F5940AC-583.
To: <sip:10562 at 1.1.1.1>;tag=8C24D454-B4128FCF.
CSeq: 101 INVITE.
Call-ID: 3C44A32A-DE0A11DB-A824A09A-38207ACB at 2.2.2.2.
Contact: <sip:9318001234567 at siphost.mydomain.com>.
Record-Route: <sip:1.1.1.1;lr=on;ftag=2F5940AC-583>.
User-Agent: PolycomSoundPointIP-SPIP_601-UA/2.1.0.2708.
Diversion: <sip:10562 at 1.1.1.1>;reason="deflection".
Content-Length: 0.
.
#
U 1.1.1.1:5060 -> 3.3.3.3:8891
ACK sip:10562 at 3.3.3.3:8891 SIP/2.0.
Via: SIP/2.0/UDP 1.1.1.1;branch=z9hG4bKe22b.4c0e7b31.0.
From: <sip:2125551212 at 2.2.2.2>;tag=2F5940AC-583.
Call-ID: 3C44A32A-DE0A11DB-A824A09A-38207ACB at 2.2.2.2.
To: <sip:10562 at 1.1.1.1>;tag=8C24D454-B4128FCF.
CSeq: 101 ACK.
User-Agent: OpenSer (1.1.0-notls (i386/linux)).
Content-Length: 0.
.
#
U 1.1.1.1:5060 -> 2.2.2.2:5060
SIP/2.0 302 Moved Temporarily.
Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bKFFC11F7D.
From: <sip:2125551212 at 2.2.2.2>;tag=2F5940AC-583.
To: <sip:10562 at 1.1.1.1>;tag=8C24D454-B4128FCF.
CSeq: 101 INVITE.
Call-ID: 3C44A32A-DE0A11DB-A824A09A-38207ACB at 2.2.2.2.
Contact: <sip:9318001234567 at siphost.mydomain.com>.
Record-Route: <sip:1.1.1.1;lr=on;ftag=2F5940AC-583>.
User-Agent: PolycomSoundPointIP-SPIP_601-UA/2.1.0.2708.
Diversion: <sip:10562 at 1.1.1.1>;reason="deflection".
Content-Length: 0.
.
#
U 2.2.2.2:5060 -> 1.1.1.1:5060
ACK sip:10562 at 1.1.1.1:5060 SIP/2.0.
Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bKFFC11F7D.
From: <sip:2125551212 at 2.2.2.2>;tag=2F5940AC-583.
To: <sip:10562 at 1.1.1.1>;tag=8C24D454-B4128FCF.
Date: Fri, 30 Mar 2007 15:29:07 GMT.
Call-ID: 3C44A32A-DE0A11DB-A824A09A-38207ACB at 2.2.2.2.
Max-Forwards: 70.
CSeq: 101 ACK.
Allow-Events: telephone-event.
Content-Length: 0.
.
#
U 2.2.2.2:59105 -> 1.1.1.1:5060
INVITE sip:9318001234567 at siphost.mydomain.com:5060 SIP/2.0.
Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bKFFC3144A.
Remote-Party-ID: <sip:
2125551212 at 2.2.2.2>;party=calling;screen=no;privacy=off.
From: <sip:2125551212 at 2.2.2.2>;tag=2F594324-39F.
To: <sip:9318001234567 at siphost.mydomain.com>.
Date: Fri, 30 Mar 2007 15:29:08 GMT.
Call-ID: 3C44A32A-DE0A11DB-A824A09A-38207ACB at 2.2.2.2.
Supported: 100rel,timer,resource-priority,replaces.
Min-SE: 1800.
Cisco-Guid: 1006091460-3725201883-2955804695-1520293600.
User-Agent: Cisco-SIPGateway/IOS-12.x.
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
SUBSCRIBE, NOTIFY, INFO, REGISTER.
CSeq: 103 INVITE.
Max-Forwards: 70.
Timestamp: 1175268548.
Contact: <sip:2125551212 at 2.2.2.2:5060>.
Diversion: <sip:10562 at 1.1.1.1>;reason=deflection.
Expires: 180.
Allow-Events: telephone-event.
Content-Type: application/sdp.
Content-Disposition: session;handling=required.
Content-Length: 268.
.
v=0.
o=CiscoSystemsSIP-GW-UserAgent 4569 6897 IN IP4 2.2.2.2.
s=SIP Call.
c=IN IP4 2.2.2.2.
t=0 0.
m=audio 18418 RTP/AVP 0 101 19.
c=IN IP4 2.2.2.2.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=rtpmap:19 CN/8000.
a=ptime:20.
#
U 1.1.1.1:5060 -> 2.2.2.2:5060
SIP/2.0 100 trying -- your call is important to us.
Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bKFFC3144A.
From: <sip:2125551212 at 2.2.2.2>;tag=2F594324-39F.
To: <sip:9318001234567 at siphost.mydomain.com>.
Call-ID: 3C44A32A-DE0A11DB-A824A09A-38207ACB at 2.2.2.2.
CSeq: 103 INVITE.
Server: OpenSer (1.1.0-notls (i386/linux)).
Content-Length: 0.
Warning: 392 1.1.1.1:5060 "Noisy feedback tells: pid=13443
req_src_ip=2.2.2.2 req_src_port=59105 in_uri=sip:9318001234567 at siptest.c
olumbia.edu:5060 out_uri=sip:18001234567 at 4.4.4.4:5060;transport=udp
via_cnt==1".
.
#
U 1.1.1.1:5060 -> 4.4.4.4:5060
INVITE sip:18001234567 at 4.4.4.4:5060;transport=udp SIP/2.0.
Record-Route: <sip:
1.1.1.1;lr=on;ftag=2F594324-39F;vsf=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA-
>.
Via: SIP/2.0/UDP 1.1.1.1;branch=z9hG4bKc22b.64968202.0.
Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bKFFC3144A.
Remote-Party-ID: <sip:
2125551212 at 2.2.2.2>;party=calling;screen=no;privacy=off.
From: <sip:2125551212 at 2.2.2.2>;tag=2F594324-39F.
Remote-Party-ID: <sip:
+12125551212 at siphost.mydomain.com>;party=calling;screen=no;privacy=off.
To: <sip:+18001234567 at siphost.mydomain.com>.
Date: Fri, 30 Mar 2007 15:29:08 GMT.
Call-ID: 3C44A32A-DE0A11DB-A824A09A-38207ACB at 2.2.2.2.
Supported: 100rel,timer,resource-priority,replaces.
Min-SE: 1800.
Cisco-Guid: 1006091460-3725201883-2955804695-1520293600.
User-Agent: Cisco-SIPGateway/IOS-12.x.
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
SUBSCRIBE, NOTIFY, INFO, REGISTER.
CSeq: 103 INVITE.
Max-Forwards: 69.
Timestamp: 1175268548.
Contact: <sip:2125551212 at 2.2.2.2:5060>.
Diversion: <sip:10562 at 1.1.1.1>;reason=deflection.
Expires: 180.
Allow-Events: telephone-event.
Content-Type: application/sdp.
Content-Disposition: session;handling=required.
Content-Length: 268.
Alert-Info: EXTERNAL.
.
v=0.
o=CiscoSystemsSIP-GW-UserAgent 4569 6897 IN IP4 2.2.2.2.
s=SIP Call.
c=IN IP4 2.2.2.2.
t=0 0.
m=audio 18418 RTP/AVP 0 101 19.
c=IN IP4 2.2.2.2.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-
#
U 1.1.1.1:5060 -> 2.2.2.2:5060
SIP/2.0 302 Moved Temporarily.
Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bKFFC11F7D.
From: <sip:2125551212 at 2.2.2.2>;tag=2F5940AC-583.
To: <sip:10562 at 1.1.1.1>;tag=8C24D454-B4128FCF.
CSeq: 101 INVITE.
Call-ID: 3C44A32A-DE0A11DB-A824A09A-38207ACB at 2.2.2.2.
Contact: <sip:9318001234567 at siphost.mydomain.com>.
Record-Route: <sip:1.1.1.1;lr=on;ftag=2F5940AC-583>.
User-Agent: PolycomSoundPointIP-SPIP_601-UA/2.1.0.2708.
Diversion: <sip:10562 at 1.1.1.1>;reason="deflection".
Content-Length: 0.
.
#
U 1.1.1.1:5060 -> 4.4.4.4:5060
INVITE sip:18001234567 at 4.4.4.4:5060;transport=udp SIP/2.0.
Record-Route: <sip:
1.1.1.1;lr=on;ftag=2F594324-39F;vsf=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA-
>.
Via: SIP/2.0/UDP 1.1.1.1;branch=z9hG4bKc22b.64968202.0.
Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bKFFC3144A.
Remote-Party-ID: <sip:
2125551212 at 2.2.2.2>;party=calling;screen=no;privacy=off.
From: <sip:2125551212 at 2.2.2.2>;tag=2F594324-39F.
Remote-Party-ID: <sip:
+12125551212 at siphost.mydomain.com>;party=calling;screen=no;privacy=off.
To: <sip:+18001234567 at siphost.mydomain.com>.
Date: Fri, 30 Mar 2007 15:29:08 GMT.
Call-ID: 3C44A32A-DE0A11DB-A824A09A-38207ACB at 2.2.2.2.
Supported: 100rel,timer,resource-priority,replaces.
Min-SE: 1800.
Cisco-Guid: 1006091460-3725201883-2955804695-1520293600.
User-Agent: Cisco-SIPGateway/IOS-12.x.
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
SUBSCRIBE, NOTIFY, INFO, REGISTER.
CSeq: 103 INVITE.
Max-Forwards: 69.
Timestamp: 1175268548.
Contact: <sip:2125551212 at 2.2.2.2:5060>.
Diversion: <sip:10562 at 1.1.1.1>;reason=deflection.
Expires: 180.
Allow-Events: telephone-event.
Content-Type: application/sdp.
Content-Disposition: session;handling=required.
Content-Length: 268.
Alert-Info: EXTERNAL.
.
v=0.
o=CiscoSystemsSIP-GW-UserAgent 4569 6897 IN IP4 2.2.2.2.
s=SIP Call.
c=IN IP4 2.2.2.2.
t=0 0.
m=audio 18418 RTP/AVP 0 101 19.
c=IN IP4 2.2.2.2.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-
On Mar 30, 2007, at 9:49 AM, Bogdan-Andrei Iancu wrote:
> Hi Zahid,
>
> is the second 302 identical to the fist? is there any ACK from
> CISCO GW to openser as response to first 302?
>
> regards,
> bogdan
>
> zm23 wrote:
>> I made a mistake saying it was a REFER method. This is happening
>> with just a 302 reply messages.
>> Any suggestions?
>>
>> Thanks.
>>
>>
>> On Mar 28, 2007, at 12:17 PM, zm23 wrote:
>>
>>> Hello All,
>>> I am trying to find out the proper/best way to handle
>>> REFERs coming from phone. My setup is as follows:
>>>
>>>
>>> Cisco gw
>>> openser phone gw 2
>>>
>>>
>>> DID
>>> 1234 -----> Invite ----------------->
>>> -------------------->
>>>
>>>
>>>
>>> <----- 302 msg <---------------------
>>> <--------------------302 moved....
>>>
>>> new #5678 sent back
>>>
>>> After receiving new invite, openser sends it out to another gateway
>>>
>>> 5678 ----> invite ---------------------->
>>> --------------------------------------------------->
>>>
>>> yet i am still seeing the 302 messages sent back from proxy to
>>> cisco gw.
>>>
>>> <------------------------------- -- 302 moved
>>>
>>>
>>> Call does connect to 5678 but is dropped after few seconds with
>>> only one way audio.
>>>
>>>
>>> What needs to be done so that when second invite hits proxy,
>>> there are no more 302s sent back?
>>>
>>> Should I process the 302 in proxy itself?
>>>
>>> What is the best way to make the 2nd call to 5678 so that it can
>>> be identified as a separate call?
>>>
>>>
>>>
>>>
>>> Thank you in advance for your help in this regards.
>>>
>>> --Zahid
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at openser.org
>>> http://openser.org/cgi-bin/mailman/listinfo/users
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at openser.org
>> http://openser.org/cgi-bin/mailman/listinfo/users
>>
>
More information about the sr-users
mailing list