Hi Albert
In general,
- responses to requests (received on TCP) should be sent to source port.
- responses to requests (received on UDP) should be sent to port
present in Via.
However there are number of parameters those can affect your destination
transport params such as maddr, sent-by, received etc.
For details I will suggest to go through RFC 3261 section 18.
Regards
Kamal
-----Original Message-----
From: Albert Rodriguez [mailto:rodriguez.alb...@gmail.com]
Sent: Tuesday, January 18, 2011 3:59 PM
To: Kamalakanta Palei (kpalei)
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] CORRECTION - SIP TCP Re Invite withdifferent
TCP Source Port
Thanks Kamal,
For clarification - is it you opinion that the SBC should be responding to
the Re Invite on the new TCP Source Port?
Thanks you for all your help!!
From: Kamalakanta Palei (kpalei)
Sent: Tuesday, January 18, 2011 4:20 AM
To: Albert Rodriguez
Cc: sip-implementors@lists.cs.columbia.edu
Subject: RE: [Sip-implementors] CORRECTION - SIP TCP Re Invite withdifferent
TCP Source Port
Hi Albert
Ethereal trace helped to some extent, see lot of lost segments, so could not
get complete message contents.
From your call flow it seems
1. The call is connected. (see the ACK message packet number – 16).
2. Looks your SBC putting “require: timer” in INVITE’s 200 OK
response.
3. That is the reason you see re-INVITE from PBX (Pkt – 17, 23 etc).
If it is going with different source port, it should be fine. I do not
think SIP restricts refresh re-INVITEs need to use same source port.
It looks at-least 2 re-INVITEs using same source port that is – 24621.
I hope with this your original question is answered.
Refresh time interval you can decide by looking at your network and max
calls supported at given point of time.
Regards,
Kamal
From: Albert Rodriguez [mailto:rodriguez.alb...@gmail.com]
Sent: Tuesday, January 18, 2011 1:46 PM
To: Kamalakanta Palei (kpalei)
Cc: Brandon W. Yuille; sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] CORRECTION - SIP TCP Re Invite withdifferent
TCP Source Port
Thanks Kamalakanta,
The Re Invite in this particular session comes at 619.8 - which is the
refresh interval set on the PBX. Acting on your advise, I reviewed the TCP
packets previous to the Re Invite and found that there are indeed TCP ACKs
from the PBX from Port 27170, and there are even responses to the TCP ACK
from my SBC.
If you don't mind, I'm including a pcap in this message. The relevent call
in this capture is the first call when you filter for VoIP Calls. The
original Invite is in Packet #7.
10.231.121.31 = PBX
10.101.1.8 = SBC
file:///C:/Users/arodriguez.JUMACORP/Desktop/flowers_filtered_2.pcap
In this capture original TCP Src Port = 24621
Other TCP Src = 27170
Thank you so much!
**Other Question: Given a very short interval of time, it is unlikely that
this behavior can be corrected in time for my customers peak period next
month. Given that the issue manifests itself with the Session Refresh
interval; can you see any potential issues with setting the PBX to a Refresh
Interval of 30000?
The only issue I can think of is the potential for a Hung Call in the event
of a IP event.
On 1/18/2011 2:27 AM, Kamalakanta Palei (kpalei) wrote:
Correcting few type errors- -----Original Message-----From:
sip-implementors-boun...@lists.cs.columbia.edu[mailto:sip-implementors-boun...@lists.cs.columbia.edu]
On Behalf OfKamalakanta Palei (kpalei)Sent: Tuesday, January 18, 2011 12:53
PMTo: Brandon W. YuilleCc: sip-implement...@lists.cs.columbia.eduSubject:
Re: [Sip-implementors] CORRECTION - SIP TCP Re Invitewithdifferent TCP
Source Port Hi AlbertFew more inputs - Your message transaction is as
below. (message1) > 10.200.100.1:TCP- 15000 -- Invite with
SDP -->10.200.100.2:TCP - 5060(message2) > 10.200.100.2:TCP- 5060 -- 200
OK --> 10.200.100.1:TCP -15000(message3) > 10.200.100.1:TCP- 16000 --
Invite with SDP -->10.200.100.2:TCP - 5060(message4) > 10.200.100.1:TCP-
5060 -- 100 Trying --> 10.200.100.2:TCP- 15000 It will be helpful to know
what is the time gap between message1 andmessage3, and complete message
transactions including those of TCPacknowledgements as well.If you can send
me the ethereal trace to me, I can give a try to findout the exact cause,
but may take sometime... I hope it may be a problem with your PBX software
(just a guess, youneed to confirm though).Once the message1 is sent, it is
expected your PBX should listen at theport 15000. I hope your PBX might not
be listening at 15000 port. Hence we do not see SBC sending further
responses (final one). To verify this capture the whole message transactions
inethereal/wireshark, after message2 , just check if PBX sent some TCP ACKor
not. If you do not see any TCP ACK from PBX side, see if you can locate
ICMPpackets from PBX side to SBC. If this is what you are seeing, then my
guess is correct, PBX is notlistening at 15000, it might be listening at
5060. RegardsKamalCisco, Bangalore -----Original Message-----From:
sip-implementors-boun...@lists.cs.columbia.edu[mailto:sip-implementors-boun...@lists.cs.columbia.edu]
On Behalf OfBrandon W. YuilleSent: Tuesday, January 18, 2011 7:20 AMTo:
sip-implement...@lists.cs.columbia.eduSubject: Re: [Sip-implementors]
CORRECTION - SIP TCP Re Invite withdifferent TCP Source Port Hi Albert, As
far as I know, the transport layer is supphosed to be transparent to the SIP
messaging. I would think what your PBX is doing is correct if the TCP
connection was broken. The PBX reconnects using a different source port
number as the previous was probably in a waiting/timeout state. The SBC
should be looking at the the usual headers to match the call and not looking
at the source port of the message to match the call (which it appears to be
doing). If the SBC has doubts about the source of the message it can always
challenge the message to be authenticated with a username and password via a
401 response. Instead, it seems to be treating it as if it is a new call or
does it just not know what to do? Either way it seems like a bug in the SBC
to me. By the way you might also want to look at what is causing the PBX to
pick a new port number. It seems that it has to be because the connection is
breaking somewhere, which means there might be bigger issues if this is
happening frequently within 300 seconds. Hope this helps,Brandon On
01/17/2011 01:21 PM, Albert Rodriguez wrote: Correction: Previous message
contained typo in sequence lines 2 and 4. CorrectSequence as follows:
10.200.100.1:TCP- 15000 -- Invite with SDP --> 10.200.100.2:TCP -5060
10.200.100.2:TCP- 5060 -- 200 OK --> 10.200.100.1:TCP -
1500010.200.100.1:TCP- 16000 -- Invite with SDP --> 10.200.100.2:TCP -5060
10.200.100.1:TCP- 5060 -- 100 Trying --> 10.200.100.2:TCP - 15000 My
apologies for the confusion. On Mon, Jan 17, 2011 at 1:07 PM, Pavesi,
Valdemar (NSN - US/Irving)mailto:valdemar.pav...@nsn.com wrote: Hello,
10.200.100.1:TCP- 15000 -- Invite with SDP --> 10.200.100.2:TCP -5060
10.200.100.2:TCP- 5060 -- 200 OK --> 10.200.100.2:TCP -
1500010.200.100.1:TCP- 16000 -- Invite with SDP --> 10.200.100.2:TCP -5060
10.200.100.2:TCP- 5060 -- 100 Trying --> 10.200.100.2:TCP - 15000 Your
Session Border ( 10.200.100.2 ) is sending the response toitself.
10.200.100.2:TCP- 5060 -- 200 OK --> 10.200.100.2:TCP -
1500010.200.100.2:TCP- 5060 -- 100 Trying --> 10.200.100.2:TCP - 15000
From IP 10.200.100.2 sending to ip 10.200.100.2 Maybe it explains why there
is a re-transmission. And forRe-tramsmission the port should never be
changed. The 100 trying must be send if the final response will take
longerthen 200ms. Rfc3261 "21.1. Provisional 1xx Provisional
responses, also known as informational responses, indicate that the server
contacted is performing some furtheraction and does not yet have a
definitive response. A server sends a 1xx response if it expects to take
more than 200 ms to obtain a final response. Note that 1xx responses are
not transmitted reliably. They never cause the client to send an ACK.
Provisional (1xx) responses MAY contain message bodies, including
sessiondescriptions. 21.1.1. 100 Trying This response indicates that the
request has been received by the next-hop server and that some unspecified
action is being taken on behalf of this call (for example, a database is
being consulted). This response, like all other provisional responses,
stops retransmissions of an INVITE by a UAC. The 100 (Trying) responseis
different from other provisional responses, in that it is never forwarded
upstream by a stateful proxy. "Regards!Valdemar -----Original
Message-----From:
sip-implementors-boun...@lists.cs.columbia.edu[mailto:sip-implementors-boun...@lists.cs.columbia.edu]
On Behalf Of extAlbert Rodriguez Sent: Monday, January 17, 2011 11:28 AMTo:
sip-implement...@lists.cs.columbia.eduSubject: [Sip-implementors] SIP TCP Re
Invite with different TCPSource Port I have configured a connection
between a Session Border Controllerand a Static SIP UA (IP PBX signaling
element) utilizing SIP over TCP.The IP PBX transmits a Re Invite with SDP at
300 seconds with a TCPSource Port different then the original Invite. The
SBC responds oncewith a "100 Trying," to the original TCP Source Port and
fails tomake any other transmissions causingthe session to eventually
timeout. Following is a shortened sequence: 10.200.100.1:TCP- 15000 --
Invite with SDP --> 10.200.100.2:TCP -5060 10.200.100.2:TCP- 5060 -- 200
OK --> 10.200.100.2:TCP - 1500010.200.100.1:TCP- 16000 -- Invite with
SDP --> 10.200.100.2:TCP -5060 10.200.100.2:TCP- 5060 -- 100 Trying -->
10.200.100.2:TCP - 15000 Questions: 1. Is this behavior supported by any SIP
RFC? 2. Is it supported by by any TCP/IP RFC? Thanks in advance for your
help! Best,Albert
_______________________________________________Sip-implementors mailing
listsip-implement...@lists.cs.columbia.eduhttps://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________Sip-implementors mailing
listsip-implement...@lists.cs.columbia.eduhttps://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________Sip-implementors mailing
listsip-implement...@lists.cs.columbia.eduhttps://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________Sip-implementors mailing
listsip-implement...@lists.cs.columbia.eduhttps://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________Sip-implementors mailing
listsip-implement...@lists.cs.columbia.eduhttps://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
