comments inline... Thanks & Regards, Nataraju A.B.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ashutosh Prakash Sent: Tuesday, January 17, 2006 1:57 PM To: [email protected] Subject: Re: [Sip-implementors] Q: can a call stateful proxy send a BYE to terminate forked INVITEs that already have 200 responses? Hi Daniel, For forked request by Proxy, BYE is not required to send, once the proxy receives final response from any one of the forked request it will generate the cancel to remaining targets where the request forked. However the Bye can be generated to caller or callee by Proxy(Call statefull proxy)once the dialog is active. This is required if your proxy interacts with some billing application. [ABN] I guess CSF should not send any BYE in any of the scenarios.. if so, in that case it acts well beyond proxy (CSF). If proxy to generate the BYE what should be the FROM and TO headers ?? , will this be sent to caller or callee ?. assume the case where in the CSF supports session timer and being started for that particular session, and session timer fires, will it generate the BYE to both caller and callee or just clean up locally and clear the call ? Even in this case the CSF clears locally and not generates the BYE request... As you mentioned the billing server scenario, I feel the call termination should have been triggered by some other entity than CSF itself... [/ABN] Regards Ashutosh. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, January 17, 2006 1:22 PM To: [email protected] Subject: Sip-implementors Digest, Vol 34, Issue 24 Send Sip-implementors mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://lists.cs.columbia.edu/cucslists/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. Q: can a call stateful proxy send a BYE to terminate forked INVITEs that already have 200 responses? (Daniel Hsueh) 2. From header (Ansari, Mohammed) 3. Questions regarding tel: URI (parveen jain) 4. Nonstandard media format (Erez Morabia) 5. Re: [Sip] sip transcation query (Nataraju A B) 6. Re: Q: can a call stateful proxy send a BYE to terminate forked INVITEs that already have 200 responses? (Nataraju A B) 7. Re: Watcher Info - notification of subscriptions (SiM) 8. Several parameter sets for the same media format (Erez Morabia) 9. Asymmetric media format (Erez Morabia) 10. Re: Asymmetric media format (Even, Roni) ---------------------------------------------------------------------- Message: 1 Date: Mon, 16 Jan 2006 17:16:05 -0500 From: Daniel Hsueh <[EMAIL PROTECTED]> Subject: [Sip-implementors] Q: can a call stateful proxy send a BYE to terminate forked INVITEs that already have 200 responses? To: [email protected] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=us-ascii; format=flowed Hello, (Apologies -- I expect this question to have been discussed already, but I'm unable to locate a discussion in the archives.) RFC3261 explicitly states that a proxy may initiate CANCELs along forked INVITE destinations when a first response comes back. I cannot locate anything saying that a BYE cannot be sent. My reading of RFC4028 Sect. 8.3 suggests that proxies MUST NOT send BYE messages. Is there a specific section of an RFC/draft that covers this exact question, or does it need to be derived from other RFC requirements? Thanks! -- Daniel Hsueh mailto:[EMAIL PROTECTED] SOMA Networks tel:+1-416-348-1631 ------------------------------ Message: 2 Date: Mon, 16 Jan 2006 17:54:05 -0500 From: "Ansari, Mohammed" <[EMAIL PROTECTED]> Subject: [Sip-implementors] From header To: <[email protected]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" Hi, Is it illegal to use an ip address in the value of a "From" header? Typically one would register with address-of-record in the "From" header and provide one's ip address in the contact header. What about the case when there is no sip registrar and hence no register. Can the "From" header be anything in outgoing requests? Please elaborate as much as you can. Thanks. Mohammed ------------------------------ Message: 3 Date: Tue, 17 Jan 2006 10:36:56 +0530 From: parveen jain <[EMAIL PROTECTED]> Subject: [Sip-implementors] Questions regarding tel: URI To: [email protected] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1 Hi All, I have some question regarding the role of proxy/Registrar in case they receives a request containing <tel:> URI . Is it possible to get the <tel:> URI in messages other then INVITE and REGISTER or in responses of any type? 1. From RFC 3261 it has been mentioned that <tel:> URI could be present in REQUEST URI , FROM and TO header, and only for REGISTER method it could be in CONTACT header. Is it possible to get it in any other header except from these? 2. Is it alright from implementation point of view to register the <tel:> URI's just like sip URI . 3. if the answer of previous question is yes, then if we are storing only <tel:> URI of a sip-phone/ PSTN-gateway , how is it possible to map <tel:> URI to sip uri if the proxy have no prior information about sip URI of that endpoint . in my opinion the sip-phone/PSTN-gateway must have to register there sip URI's with DNS by any other mean and proxy can contact that DNS for any mapping using ENUM, please correct me if I am wrong ? any help regarding the same will be highly appreciated .Please excuse if I had not formed my question's well. Thanks & Regards, Parveen ------------------------------ Message: 4 Date: Tue, 17 Jan 2006 07:45:33 +0200 From: "Erez Morabia" <[EMAIL PROTECTED]> Subject: [Sip-implementors] Nonstandard media format To: <[email protected]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="windows-1255" Hi, According to RFC 2327, SDP, section 6: ?For media whose transport protocol is not RTP or UDP the format field is protocol specific.? Such formats should be defined in an additional specification document.? So, if I want to add my own nonstandard media-format to media with transport TCP, should I document it in some standard? If yes, where? For example, m=control 1234 tcp MyNonStandardFormat c=IN IP4 10.10.10.10 a=fmtp: MyNonStandardFormat Data={bla bla bla} When I write application that parses such SDP, should I make my application ignore such ?unknown? formats? Thanks, Erez ------------------------------ Message: 5 Date: Tue, 17 Jan 2006 11:20:41 +0530 From: "Nataraju A B" <[EMAIL PROTECTED]> Subject: Re: [Sip-implementors] [Sip] sip transcation query To: "'thejeswara reddy'" <[EMAIL PROTECTED]>, "'VikramB'" <[EMAIL PROTECTED]> Cc: [email protected] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" Additional comments inline... Thanks & Regards, Nataraju A.B. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of thejeswara reddy Sent: Monday, January 16, 2006 1:15 PM To: VikramB; [email protected] Cc: [email protected] Subject: Re: [Sip-implementors] [Sip] sip transcation query hai vikram , ACK is considered as part of Transaction for non-2xx final responses. because Trasacation will not be considered as closed until the recepion of ACK , ensures the reliable delivery of non-2XX final responses to client. [ABN] 1. for transaction to complete the ACK is required for non-2xx whereas not required for 2xx response (soon after 2xx-to-INV received it would be terminated, hence no need to pass the ACK through those set of proxies which carried the INV)... (Also ACK for 2xx is required to complete the SDP negotiation than to complete the transaction state machine.) 2. All the entities involved in reaching the INV to target runs the transaction state machine (except stateless proxies) which need to completed gracefully by acknowledging the suitable ACK, hence the ACK for non-2xx of INV is hop-by-hop and would pass through all the proxies which carried INV. Hope this clarifies your doubt...? thanks theja "VikramB"<[EMAIL PROTECTED]> wrote: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=Content-Type content="text/html; charset=iso-8859-1"> <META content="MSHTML 6.00.2900.2802" name=GENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=#ffffff> <DIV><FONT face=Arial size=2>Hello All,</FONT></DIV> <DIV><FONT face=Arial size=2>   ; In rfc 3261 section 6 Definition </FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2><STRONG> SIP Transaction : </STRONG></FONT></DIV> <DIV><STRONG><FONT face=Arial size=2>   ;   ; ...</FONT></STRONG></DIV> <DIV><STRONG><FONT face=Arial size=2>   ;   ; ....</FONT></STRONG></DIV> <DIV><FONT face=Arial size=2><STRONG> &nb sp; &nb sp; </S TRONG> If the request is INVITE and the final response is a non-2xx, the transaction also<BR> includes an ACK to the response. The ACK for a 2xx response to an INVITE request is a separate transaction.</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2> My query is why ACK is considered as a part of same transaction when in case of non-2xx response.?</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>regards</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>VIkram</FONT></DIV></BODY></HTML> Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy The Best In BOOKS at http://www.bestsellers.indiatimes.com Bid for for Air Tickets @ Re.1 on Air Sahara Flights. Just log on to http://airsahara.indiatimes.com and Bid Now! _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ------------------------------ Message: 6 Date: Tue, 17 Jan 2006 11:31:07 +0530 From: "Nataraju A B" <[EMAIL PROTECTED]> Subject: Re: [Sip-implementors] Q: can a call stateful proxy send a BYE to terminate forked INVITEs that already have 200 responses? To: "'Daniel Hsueh'" <[EMAIL PROTECTED]>, <[email protected]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" Comments inline.. Thanks & Regards, Nataraju A.B. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Hsueh Sent: Tuesday, January 17, 2006 3:46 AM To: [email protected] Subject: [Sip-implementors] Q: can a call stateful proxy send a BYE to terminate forked INVITEs that already have 200 responses? Hello, (Apologies -- I expect this question to have been discussed already, but I'm unable to locate a discussion in the archives.) RFC3261 explicitly states that a proxy may initiate CANCELs along forked INVITE destinations when a first response comes back. I cannot locate anything saying that a BYE cannot be sent. My reading of RFC4028 Sect. 8.3 suggests that proxies MUST NOT send BYE messages. [ABN] this does mean, the proxy should not generate the BYE or any other message, with an exception, and it can generate CANCEL on reception of 2xx or 6xx to INV. Hence it's been mentioned as MUST not send BYE (implicitly mean should not trigger BYE from itself). If it receives the BYE from UAC/UAS then it has to forward / fork depending on the prevailing conditions. Is there a specific section of an RFC/draft that covers this exact question, or does it need to be derived from other RFC requirements? Thanks! -- Daniel Hsueh mailto:[EMAIL PROTECTED] SOMA Networks tel:+1-416-348-1631 _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ------------------------------ Message: 7 Date: Tue, 17 Jan 2006 06:07:39 +0000 (GMT) From: SiM <[EMAIL PROTECTED]> Subject: Re: [Sip-implementors] Watcher Info - notification of subscriptions To: Sip-Implementors <[email protected]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=iso-8859-1 Arjun Roychowdhury <[EMAIL PROTECTED]> wrote: Hi, RFC 3857 "A Watcher Information Event Template-Package...." defines a mechanism by which a user can subscribe to subscription changes to a particular event package. I am working on a situation where user 'A' is the 'moderator' of a particular event package X that is hosted in a central presence server P. A subscribes to P with event:X.winfo. Now when B subscribes to P for event X, P notifies A of this occurence. However, 3857 provides no standard mechanism in which A can instruct/deny this request (3857 leaves this as 'out of scope'). Is there any draft / mechanism that allows an explicity 'allow / deny' mechanim via SIP that A can use to instruct P to deny the subscription to B ? regds arjun Hi Arjun, I'am not sure whether you are looking for the below Internet draft on Presence Authorization Rules, where a user can, express his/her intent (Rule) to share presence information, to a particular Subscriber . It uses XCAP , to manipulate the information in the Presence Authorization Rules Document. http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-rules-04. txt However, i do not know the status of the latest version of this ID. Cheers. Simith Send instant messages to your online friends http://in.messenger.yahoo.com ------------------------------ Message: 8 Date: Tue, 17 Jan 2006 08:16:10 +0200 From: "Erez Morabia" <[EMAIL PROTECTED]> Subject: [Sip-implementors] Several parameter sets for the same media format To: <[email protected]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="US-ASCII" Hi, How do I announce that I have capability to support specific video codec with several parameter sets? For example: Supporting H.261 with: 1) CIF, 30fps, 256Kbps 2) QCIF, 15fps, 52Kbps According to RFC 2327, SDP, section 6: "Up to one rtpmap attribute can be defined for each media format specified". As far as I can see, I have the following 2 options: Option 1 - duplicated media formats m=video 6794 RTP/AVP 31 31 a=rtpmap:31 H261/90000 a=fmtp:31 CIF=1/MaxBR%60 a=rtpmap:31 H261/90000 a=fmtp:31 QCIF=2/MaxBRR0 Option 2 - duplicated media fields m=video 6794 RTP/AVP 31 31 a=rtpmap:31 H261/90000 a=fmtp:31 CIF=1/MaxBR%60 m=video 6794 RTP/AVP 31 31 a=rtpmap:31 H261/90000 a=fmtp:31 QCIF=2/MaxBRR0 Are there any other options? Is it the right way to do it? Does SDP allow me to do it at all? Thanks, Erez ------------------------------ Message: 9 Date: Tue, 17 Jan 2006 08:23:22 +0200 From: "Erez Morabia" <[EMAIL PROTECTED]> Subject: [Sip-implementors] Asymmetric media format To: <[email protected]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="US-ASCII" Hi, Suppose I want to announce different format parameters for the receive direction and for the transmit direction. For example, Receive : QCIF, 110Kbps, 15fps Transmit: CIF, 440Kbps, 30fps Is there a way for doing it? The only thing I can think of is: m=video 6794 RTP/AVP 31 a=rtpmap:31 H261/90000 a=fmtp:31 CIF=1/MaxBRD00 a=sendonly m=video 6794 RTP/AVP 31 a=rtpmap:31 H261/90000 a=fmtp:31 QCIF=2/MaxBR00 a=recvonly Thanks, Erez ------------------------------ Message: 10 Date: Tue, 17 Jan 2006 09:51:27 +0200 From: "Even, Roni" <[EMAIL PROTECTED]> Subject: Re: [Sip-implementors] Asymmetric media format To: "Erez Morabia" <[EMAIL PROTECTED]>, <[email protected]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" Hi, I think it is OK. The problem I see is with the MaxBR field. I am not aware that it is in the payload specification. You should use b=AS:440 or b=TIAS:440000 for each m line Roni Even -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Erez Morabia Sent: Tuesday, January 17, 2006 8:23 AM To: [email protected] Subject: [Sip-implementors] Asymmetric media format Hi, Suppose I want to announce different format parameters for the receive direction and for the transmit direction. For example, Receive : QCIF, 110Kbps, 15fps Transmit: CIF, 440Kbps, 30fps Is there a way for doing it? The only thing I can think of is: m=video 6794 RTP/AVP 31 a=rtpmap:31 H261/90000 a=fmtp:31 CIF=1/MaxBRD00 a=sendonly m=video 6794 RTP/AVP 31 a=rtpmap:31 H261/90000 a=fmtp:31 QCIF=2/MaxBR00 a=recvonly Thanks, Erez _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ------------------------------ _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors End of Sip-implementors Digest, Vol 34, Issue 24 ************************************************ _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
