[Sip-implementors] Expires: header field w/ missing expiration param
What should the behavior of a registrar be if it receives a REGISTER request w/ an Expires: header that has no expiration parameter? In other words, instead of getting Expires: 3600 it gets Expires: I looked briefly through Section 7 of 3261 and didn't immediately see anything addressing this anomalous case. On the one hand I could see a case for just dropping the message (since it's malformed); on the other hand, a robust implementation might want to reply w/ 200 OK that has a default expiration value associated with it. Thanks, Jeffrey Wright System Test Engineering Manager Aztek Networks ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
[Sip-implementors] Question on interpretation of wording in RFC3261, Section 10.3
Hello, I have a question with interpreting the wording of RFC3261 with respect to how a SIP registrar should respond to REGISTER requests that do not have a Contact: field in the message (this is the method specified for performing a "binding fetch" from a registrar). According to 3261, Section 10.3, Step 8: 8. The registrar returns a 200 (OK) response. The response MUST contain Contact header field values enumerating all current bindings. Each Contact value MUST feature an "expires" parameter indicating its expiration interval chosen by the registrar. The response SHOULD include a Date header field. The way I originally read this is that a registrar should respond w/ the expiration value chosen at the moment of registration (e.g. 3600). This value would not change during the time in which that registration is valid (not expired). However, what I am actually seeing from a real registrar is that 200OK responses are given with the count-down to the expiration (e.g. 3455, then 3300, then 2988) as subsequent REGISTER requests w/ no Contact: headers are sent - this instead of what I expected, the static (originally set) expiration value. Anyone care to weigh in on the interpretation of the RFC's wording? "Each Contact value MUST feature an "expires" parameter indicating its expiration interval chosen by the registrar." Thanks in advance, Jeffrey D. Wright System Test Engineering Manager Aztek Networks, Inc. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
[Sip-implementors] Is a SUBSCRIBE request ever fielded by a UA instead of a proxy?
Hello, I have a question regarding the SUBSCRIBE method. Is there ever a situation in which a SUBSCRIBE request would be sent from one UA to another UA, instead of directed at a SIP proxy? In other words, would a UA ever be the target of a SUBSCRIBE request? From what I understand, a typical SUBSCRIBE/NOTIFY transaction would involve a UA and a SIP proxy server, for applications such as voicemail or presence. In such cases, the UA sends a SUBSCRIBE to the proxy for a specific event package, and is subsequently notified by the server hosting the event package when an internal state change requires notification of subscribers. But is it conceivable that a UA would ever host an event package itself, and respond to SUBSCRIBE notifications directed at it? Thanks in advance. Hope my question makes sense. Jeffrey D. Wright System Test Engineering Manager Aztek Networks, Inc. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Header fields in the B2BUA scenario
A B2BUA is a user agent, not a proxy. It acts as a user agent on behalf of other user agents (so it is involved in registration, call setup / teardown, etc.). Unfortunately the RFCs don't give a lot of direction to their specific implementation. That said, to me, a B2BUA should act so that any alteration of header fields or parameters should be within the spirit of maintaining the call flow originated by the UAs being served by the B2BUA. They should be as transparent as possible and not interfere with or disallow any features attempted by the UAs. Jeffrey Wright System Test Engineering Manager Aztek Networks -Original Message- From: [EMAIL PROTECTED] on behalf of Stephan Steiner Sent: Sun 2/17/2008 4:34 AM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Header fields in the B2BUA scenario Hi I have a SIP PBX which works in B2BUA mode and I've noted that when it comes to dealing with Header fields, it doesn't stick to the table 2 in chapter 20.1 of RFC 3261. Specifically, it is modifying some header fields which according to that table may not be modifed by a proxy. I contacted the manufacturer and they claim that since a B2BUA isn't a proxy, they don't have to follow the rules established in the RFC and I'm having a hard time countering that since to me, a B2BUA is a proxy seeing as it does what a proxy does (even if the RFC doesn't spell that out) but I'm wondering: Is there any type of UAS to which the header processing rules mentioned before do not apply? Is B2BUA really a loophole to not do things a proxy should do just because it isn't a real proxy per definition (even though it basically does the same things.. it just does more than a proxy does)? Regards Stephan ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://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
[Sip-implementors] Are UA calls w/o registration allowed?
Hello, Is there any mandate in the RFCs (or elsewhere) that states that a UA cannot initiate a call w/o first registering with a registrar? I've noticed that some UA implementations (softphones and VoIP GWs alike) allow the user to initiate a call even when there is no active registration, while other implementations disallow calls. I looked through 3261 and didn't see anything specifically requiring a registration in Section 13, "Initiating a Session." Thanks in advance, Jeffrey D. Wright System Test Engineering Manager Aztek Networks, Inc. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Is it acceptable to have "methods=" param in theContact header for a REGISTER message
Do the spaces matter for SIP messages or their contents? According to 3840, the definitions for the "methods=" Feature Tag are in compliance with RFC2730, which specifies both textual and non-textual (ASN.1 encoded) representations for negotiating capabilities. I would be surprised if a SIP implementation - which is text based almost by definition - specified ASN.1 encoding for its message contents. Then again, what do I know? I certainly haven't read the entire RFC. :-) Jeffrey D. Wright System Test Engineering Manager Aztek Networks, Inc. -Original Message- From: Paul Kyzivat [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 19, 2007 7:31 PM To: Jeff Wright Cc: Amit P. Ahuja; sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Is it acceptable to have "methods=" param in theContact header for a REGISTER message Right. I would however mention that the spaces within the quoted string value are incorrect. So it should be: Contact: sip:[EMAIL PROTECTED]:5060;methods="INVITE,ACK,BYE,CANCEL,OPTIONS,INFO,MES SAGE,SUBSCRIBE,NOTIFY,PRACK,UPDATE,REFER" Paul Jeff Wright wrote: > Hello, > > I just stumbled across this myself in the following RFC: > > http://tools.ietf.org/html/rfc3840 > > See in particular Section 6, "Expressing Capabilities in a > Registration." > > Best regards, > > Jeffrey D. Wright > System Test Engineering Manager > Aztek Networks, Inc. > (303) 415 6149 > [EMAIL PROTECTED] > > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Amit P. Ahuja > Sent: Wednesday, December 19, 2007 4:05 PM > To: sip-implementors@lists.cs.columbia.edu > Subject: [Sip-implementors] Is it acceptable to have "methods=" param in > theContact header for a REGISTER message > > One of the SIP hardphones that I use sends out a REGISTER message with > the > Contact header that looks like: > > Contact: sip:[EMAIL PROTECTED]:5060;methods="INVITE, ACK, BYE, CANCEL, > OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, REFER" > > I could not find whether the "methods=" param in the Contact is > acceptable > as per RFC3261. I thought Allow: is the only way of specifying supported > > methods. > Would someone know if it is valid and which RFC specifies so? > > Thanks and Regards, > Amit Ahuja > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://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 > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] Is it acceptable to have "methods=" param in theContact header for a REGISTER message
Hello, I just stumbled across this myself in the following RFC: http://tools.ietf.org/html/rfc3840 See in particular Section 6, "Expressing Capabilities in a Registration." Best regards, Jeffrey D. Wright System Test Engineering Manager Aztek Networks, Inc. (303) 415 6149 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Amit P. Ahuja Sent: Wednesday, December 19, 2007 4:05 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Is it acceptable to have "methods=" param in theContact header for a REGISTER message One of the SIP hardphones that I use sends out a REGISTER message with the Contact header that looks like: Contact: sip:[EMAIL PROTECTED]:5060;methods="INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, REFER" I could not find whether the "methods=" param in the Contact is acceptable as per RFC3261. I thought Allow: is the only way of specifying supported methods. Would someone know if it is valid and which RFC specifies so? Thanks and Regards, Amit Ahuja ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://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
