Jeroen Yes, it looks like the rport is also something which the client side is supposed to put. So in his example, if the UAC put the rport to be 45000, then only the response will go back to 45000. its more like a NAT scenario. But I guess based on the spec( and for stateless servers), for the port number, the proxy depends on the VIA field or the rport parameter in the VIA and if it cant find any port then by default it will try 5060. But there are other ways to find the port number the UAC is listening on. So yes in the end, it would be a hit and trial based on the VIA
Manpreet -----Original Message----- From: Jeroen van Bemmel [mailto:[EMAIL PROTECTED] Sent: Monday, October 03, 2005 6:27 PM To: Manpreet Singh; [email protected] Subject: Re: [Sip-implementors] RE: Reply to a REGISTER Manpreet, Are you refering to the 'received' parameter? According to RFC3261 that can only contain the IP address (v4/v6) but not the port. The 'rport' parameter contains the port, but a UAS is currently only allowed to use that when the client requested it I encountered several clients that use bogus ports in their Via headers, so I resorted to the 'rport' even though the client did not ask for it. Problem is that it is not possible to determine if a via port is bogus without trying it out Regards, Jeroen ----- Original Message ----- From: "Manpreet Singh" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Monday, October 03, 2005 5:26 PM Subject: [Sip-implementors] RE: Reply to a REGISTER > 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 _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
