The VIA fiels is for sure used by statesless proxies ( even stateful) to
respond back but the session takes precedence over the VIA. So if the VIA
parameters are different than the actualy source IP/port pair, the proxy,
be
in stateless or stateful must insert a recvd paramater in the VIA field.
So
yes the responses will go based on the session ( UDP or TCP) and the proxy
will not rely on the VIA header only. For stateless, because it has
inserted
the recvd paramater, it will know where to respond back.
So in your context, even when the port in the message is 5060 but the
actual
source port is 45000, the response will go back to 45000 as this part is
added by the proxy in the VIA when it sees the mismatch. So all downstream
requests will carry that recvd header stating port 45000.
Thanks
Manpreet
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Monday, October 03, 2005 10:27 AM
To: [email protected]
Subject: Sip-implementors Digest, Vol 31, Issue 3
Send Sip-implementors mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific than
"Re: Contents of Sip-implementors digest..."
Today's Topics:
1. Reply to a REGISTER ([EMAIL PROTECTED])
2. multiple ptime question (Gummadidala, Ravi)
3. RE: RFC 3389 Comfort Noise (Frank W. Miller)
4. Re: Query regarding 183 provisional response. (Paul Kyzivat)
5. Stateless proxy and record-route (Ar c'hasour)
6. RE: Stateless proxy and record-route (Manjunath Warad)
7. SER Server behind NAT (Abdul Lateef)
8. Re: Stateless proxy and record-route (Diego B)
9. Re: Reply to a REGISTER (Dale R. Worley)
----------------------------------------------------------------------
Message: 1
Date: Sun, 2 Oct 2005 10:16:26 -0400
From: [EMAIL PROTECTED]
Subject: [Sip-implementors] Reply to a REGISTER
To: [email protected]
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset="iso-8859-1"
Hi all,
Aren't the replies to all request messages supposed to be sent in the
context of the original UDP/TCP session?
I know there're VIA fields that indicate how to send the reply, but I
thought that whatever the via fields contain should correspond to the
actual
source IP address and source port number used in the request?
Aren't VIAs there only to help stateless PROXY servers that just don't
remember from what ip/port they received the original request?
The context of my question is that I encountered a UA client that sends a
REGISTER message from port, let's say 45000, but puts 5060 in the VIA
field.
Thank,
Andy.
------------------------------
Message: 2
Date: Sun, 2 Oct 2005 20:01:10 -0700
From: "Gummadidala, Ravi" <[EMAIL PROTECTED]>
Subject: [Sip-implementors] multiple ptime question
To: <[email protected]>
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset="iso-8859-1"
I know that this has been discussed in the past but I am not sure what the
conclusion/concensus was. The question is whether attributes like ptime
are
codec-specific or media specific? Some people have argued that these are
media specific properties and it is invalid for a SDP m line to have
multiple ptime values. The other school of thought claims that ptime is a
codec specific attribute. I am also inclined to go with the latter. Say in
the m line a UA advertises support for EVRC and G723. EVRC is a 20ms frame
based codec while G723 is a 30ms frame based codec. How should such an SDP
be formulated if it is invalid to have multiple ptimes in a media line?
Please accept my apologies if this topic has been discussed ad nauseam in
the past.
Thanks,
-Ravi.
------------------------------
Message: 3
Date: Sun, 02 Oct 2005 23:13:53 -0400
From: "Frank W. Miller" <[EMAIL PROTECTED]>
Subject: RE: [Sip-implementors] RFC 3389 Comfort Noise
To: Uzi Doron <[EMAIL PROTECTED]>
Cc: [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=utf-8
Inline...
On Sun, 2005-10-02 at 08:37 +0200, Uzi Doron wrote:
Hi Frank
Is the payload type of these CN packets 13 ?
The payload type is 19, which I believe was the old value for the same
thing. My client accepts both payload types.
It is interesting to see the full SDP of this session. I would assume
that the two UAs have to negotiate the use of payload type 13 in the
Actually no. Neither 13 or 19 appears and any of the SDP. The INVITE is
initiated by my client to the Cisco box (as the trace shows) and then the
Cisco box does a re-INVITE that changes the port number on the Cisco side.
In the four messages in which SDP appears, no mention of 13 or 19 is
there.
SDP. We've come across at least one UA that does not support this
payload type, and that if you do send it such a packet - it will
generate a terrible scratching noise. So how was it in your case –
have the two sides agreed on using payload type 13 ?
The behavior my client is displaying currently is a choppiness on the
playback of the inbound stream, working on it...
Thanks for the tips!
FM
------------------------------
Message: 4
Date: Sun, 02 Oct 2005 23:34:50 -0400
From: Paul Kyzivat <[EMAIL PROTECTED]>
Subject: Re: [Sip-implementors] Query regarding 183 provisional
response.
To: [EMAIL PROTECTED]
Cc: [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
[EMAIL PROTECTED] wrote:
In this call flow I don't think it is correct to send session description
in 180. As per the two statements below **reliable non-failure message**
183
completed the offer/answer exchange, so resending answer is incorrect.
Oh, I missed that the 180 wasn't reliable. (Its hard to be sure what is
intended without the actual messages, but no prack is shown for it, so I
guess it isn't.)
Yeah, if it isn't reliable, then it shouldn't have SDP.
Paul
RFC 3261, section 13.2.1:
If the initial offer is in an INVITE, the answer MUST be in a **reliable
non-failure message** from UAS back to UAC which is correlated to that
INVITE. For this specification, that is only the final 2xx response to
that
INVITE. That same exact answer MAY also be placed in any provisional
responses sent **prior to the answer**.
RFC 3262, section 5:
All user agents that support this extension MUST support all offer/answer
exchanges that are possible based on the rules in Section 13.2 of RFC
3261,
based on the existence of INVITE and PRACK as requests, and 2xx and
**reliable 1xx as non-failure reliable responses**.
As per the statement below from RFC3261, section 13.2.1, sending an offer
is incorrect.
"Once the UAS has sent or received an answer to the initial offer, it
MUST
NOT generate subsequent offers in any responses to the initial INVITE."
-Ramakrishna
________________________________
From: [EMAIL PROTECTED] on behalf of Neeraj
Jain
Sent: Sat 10/1/2005 10:49 AM
To: 'Sip-Implementors'
Subject: RE: [Sip-implementors] Query regarding 183 provisional response.
Please see inline comments.
Neeraj Jain
BayPackets Technologies
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of jay
prakash dubey
Sent: Friday, September 30, 2005 12:26 PM
To: Sip-Implementors
Subject: [Sip-implementors] Query regarding 183 provisional response.
Hi all,
I am having one basic doubt in Prvisional response.If 180 ringing and
183 session progress both came from UAS to UAC.
-----------INVITE+SDP------------------->
<----------183 Session progress(SDP)---------
------------PRACK----------------------->
<------------180 Ringing(SDP)---------------- <------------200 Ok
(for PRACK)--------------- <------------200 Ok (for
INVITE)--------------
-------------------- --------------ACK( for Invite)---------->
1. what happen if 200 Ok for PRACK doesn"t recieve.call droped or not?
[NEERAJ] UAS in this flow is violating RFC3262 which says that a UAS
must not respond with final response to INVITE until there is an
outstanding provisional response containing SDP (which is 180 Ringing in
this case).
Hence 200 Ok (for INVITE) must not be sent before the PRACK is
received for 180 Ringing.
2. if 183 and 180 both has SDP than when final SDP negotiation can be
done in 200 OK (PRACK)?
[NEERAJ] Again as per RFC3262, SDP in 180 must be same as that in 183
unless PRACK (183) contains additional offer from UAC. In later case,
180 must have the same SDP as 200 OK (PRACK).
can any body clarify this call flow as in my application Early media
is must....
Thanks and regards
Jay
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Confidentiality Notice
The information contained in this electronic message and any
attachments to this message are intended for the exclusive use of the
addressee(s) and may contain confidential or privileged information.
If you are not the intended recipient, please notify the sender at Wipro
or [EMAIL PROTECTED] immediately and destroy all copies of this message
and any attachments.
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
------------------------------
Message: 5
Date: Sun, 2 Oct 2005 23:31:12 -0700 (PDT)
From: "Ar c'hasour" <[EMAIL PROTECTED]>
Subject: [Sip-implementors] Stateless proxy and record-route
To: [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=iso-8859-1
Hi,
Can a stateless proxy record-route?
Thanks,
P. Kasour
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
------------------------------
Message: 6
Date: Mon, 03 Oct 2005 14:48:41 +0800
From: Manjunath Warad <[EMAIL PROTECTED]>
Subject: RE: [Sip-implementors] Stateless proxy and record-route
To: "'Ar c'hasour'" <[EMAIL PROTECTED]>,
[email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=US-ASCII
Hi,
Yes, stateless proxies can record-route. But I don't see any use
case of stateless proxy record-routing.
Manju
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ar c'hasour
Sent: Monday, October 03, 2005 2:31 PM
To: [email protected]
Subject: [Sip-implementors] Stateless proxy and record-route
Hi,
Can a stateless proxy record-route?
Thanks,
P. Kasour
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
------------------------------
Message: 7
Date: Mon, 3 Oct 2005 03:19:22 -0700 (PDT)
From: Abdul Lateef <[EMAIL PROTECTED]>
Subject: [Sip-implementors] SER Server behind NAT
To: [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=iso-8859-1
Hi all,
Is it possible to use SER server behind NAT with some modification in
router. I have my Linux box connected to our Office Lan with SpeedTouch
Router, the Router is having public IP Address. I want to install SER in
my
linux box to make full test.
If possible how i can do it?
--------
Yours,
Abdul Lateef
Computer Programmer
HATIF COM
Mob: +974 - 5405022
Tel: +974 - 4883068
ICQ: 276994704
YM!: abdul_zu
Fax: +974 - 4883063
Doha Qatar
http://www.hatif.com
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
------------------------------
Message: 8
Date: Mon, 03 Oct 2005 13:51:40 +0200
From: Diego B <[EMAIL PROTECTED]>
Subject: Re: [Sip-implementors] Stateless proxy and record-route
To: [EMAIL PROTECTED]
Cc: 'Ar c'hasour' <[EMAIL PROTECTED]>, [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi;
One example is a scenario with a port restricted NAT where, for example,
the
ACK must come from the Proxy.
Regards
Diego B
Manjunath Warad wrote:
Hi,
Yes, stateless proxies can record-route. But I don't see any use
case
of stateless proxy record-routing.
Manju
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ar
c'hasour
Sent: Monday, October 03, 2005 2:31 PM
To: [email protected]
Subject: [Sip-implementors] Stateless proxy and record-route
Hi,
Can a stateless proxy record-route?
Thanks,
P. Kasour
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
------------------------------
Message: 9
Date: Mon, 03 Oct 2005 10:26:27 -0400
From: "Dale R. Worley" <[EMAIL PROTECTED]>
Subject: Re: [Sip-implementors] Reply to a REGISTER
To: Sip-Implementors <[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain
On Sun, 2005-10-02 at 10:16 -0400, [EMAIL PROTECTED] wrote:
Aren't the replies to all request messages supposed to be sent in the
context of the original UDP/TCP session?
The rules are complicated, but I believe that that is not the case -- a
reply is to be sent to the address specified in the Via, which may not be
the address from which the request was sent.
Dale
------------------------------
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
End of Sip-implementors Digest, Vol 31, Issue 3
***********************************************
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
