28 Mar
2007
28 Mar
'07
7:17 p.m.
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 refer <---------------------
<--------------------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
29 Mar
29 Mar
4:31 p.m.
New subject: [Users] how to handle 302-moved temporarily
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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
30 Mar
30 Mar
4:49 p.m.
New subject: [Users] how to handle 302-moved temporarily
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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
1 Apr
1 Apr
12:12 a.m.
New subject: [Users] how to handle 302-moved temporarily
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@2.2.2.2>;tag=2F5940AC-583.
To: <sip:10562@1.1.1.1>;tag=8C24D454-B4128FCF.
CSeq: 101 INVITE.
Call-ID: 3C44A32A-DE0A11DB-A824A09A-38207ACB(a)2.2.2.2.
Contact: <sip:9318001234567@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@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@1.1.1.1:5060 SIP/2.0.
Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bKFFC11F7D.
From: <sip:2125551212@2.2.2.2>;tag=2F5940AC-583.
To: <sip:10562@1.1.1.1>;tag=8C24D454-B4128FCF.
Date: Fri, 30 Mar 2007 15:29:07 GMT.
Call-ID: 3C44A32A-DE0A11DB-A824A09A-38207ACB(a)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@2.2.2.2>;tag=2F5940AC-583.
To: <sip:10562@1.1.1.1>;tag=8C24D454-B4128FCF.
CSeq: 101 INVITE.
Call-ID: 3C44A32A-DE0A11DB-A824A09A-38207ACB(a)2.2.2.2.
Contact: <sip:9318001234567@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@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@2.2.2.2>;tag=2F5940AC-583.
To: <sip:10562@1.1.1.1>;tag=8C24D454-B4128FCF.
CSeq: 101 INVITE.
Call-ID: 3C44A32A-DE0A11DB-A824A09A-38207ACB(a)2.2.2.2.
Contact: <sip:9318001234567@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@1.1.1.1>;reason="deflection".
Content-Length: 0.
.
#
U 1.1.1.1:5060 -> 3.3.3.3:8891
ACK sip:10562@3.3.3.3:8891 SIP/2.0.
Via: SIP/2.0/UDP 1.1.1.1;branch=z9hG4bKe22b.4c0e7b31.0.
From: <sip:2125551212@2.2.2.2>;tag=2F5940AC-583.
Call-ID: 3C44A32A-DE0A11DB-A824A09A-38207ACB(a)2.2.2.2.
To: <sip:10562@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@2.2.2.2>;tag=2F5940AC-583.
To: <sip:10562@1.1.1.1>;tag=8C24D454-B4128FCF.
CSeq: 101 INVITE.
Call-ID: 3C44A32A-DE0A11DB-A824A09A-38207ACB(a)2.2.2.2.
Contact: <sip:9318001234567@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@1.1.1.1>;reason="deflection".
Content-Length: 0.
.
#
U 2.2.2.2:5060 -> 1.1.1.1:5060
ACK sip:10562@1.1.1.1:5060 SIP/2.0.
Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bKFFC11F7D.
From: <sip:2125551212@2.2.2.2>;tag=2F5940AC-583.
To: <sip:10562@1.1.1.1>;tag=8C24D454-B4128FCF.
Date: Fri, 30 Mar 2007 15:29:07 GMT.
Call-ID: 3C44A32A-DE0A11DB-A824A09A-38207ACB(a)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@siphost.mydomain.com:5060 SIP/2.0.
Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bKFFC3144A.
Remote-Party-ID: <sip:
2125551212(a)2.2.2.2>;party=calling;screen=no;privacy=offoff.
From: <sip:2125551212@2.2.2.2>;tag=2F594324-39F.
To: <sip:9318001234567@siphost.mydomain.com>.
Date: Fri, 30 Mar 2007 15:29:08 GMT.
Call-ID: 3C44A32A-DE0A11DB-A824A09A-38207ACB(a)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@2.2.2.2:5060>.
Diversion: <sip:10562@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@2.2.2.2>;tag=2F594324-39F.
To: <sip:9318001234567@siphost.mydomain.com>.
Call-ID: 3C44A32A-DE0A11DB-A824A09A-38207ACB(a)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@siptest.c
olumbia.edu:5060 out_uri=sip:18001234567@4.4.4.4:5060;transport=udp
via_cnt==1".
.
#
U 1.1.1.1:5060 -> 4.4.4.4:5060
INVITE sip:18001234567@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(a)2.2.2.2>;party=calling;screen=no;privacy=offoff.
From: <sip:2125551212@2.2.2.2>;tag=2F594324-39F.
Remote-Party-ID: <sip:
+12125551212(a)siphost.mydomain.com>;party=calling;screen=no;privacy=offoff.
To: <sip:+18001234567@siphost.mydomain.com>.
Date: Fri, 30 Mar 2007 15:29:08 GMT.
Call-ID: 3C44A32A-DE0A11DB-A824A09A-38207ACB(a)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@2.2.2.2:5060>.
Diversion: <sip:10562@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@2.2.2.2>;tag=2F5940AC-583.
To: <sip:10562@1.1.1.1>;tag=8C24D454-B4128FCF.
CSeq: 101 INVITE.
Call-ID: 3C44A32A-DE0A11DB-A824A09A-38207ACB(a)2.2.2.2.
Contact: <sip:9318001234567@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@1.1.1.1>;reason="deflection".
Content-Length: 0.
.
#
U 1.1.1.1:5060 -> 4.4.4.4:5060
INVITE sip:18001234567@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(a)2.2.2.2>;party=calling;screen=no;privacy=offoff.
From: <sip:2125551212@2.2.2.2>;tag=2F594324-39F.
Remote-Party-ID: <sip:
+12125551212(a)siphost.mydomain.com>;party=calling;screen=no;privacy=offoff.
To: <sip:+18001234567@siphost.mydomain.com>.
Date: Fri, 30 Mar 2007 15:29:08 GMT.
Call-ID: 3C44A32A-DE0A11DB-A824A09A-38207ACB(a)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@2.2.2.2:5060>.
Diversion: <sip:10562@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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
6446
days inactive
6449
days old
3 comments
2 participants
participants (2)
-
Bogdan-Andrei Iancu -
zm23