Re: [Sip-implementors] Session-level value overriden by media-levelvalue in SDP (RFC 4566)

Comments inline... Regards, Nataraju A B From: Jagan Mohan [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 12, 2007 12:49 PM To: Nataraju Alilughatta basavaraju (WT01 - TES-Mobility & Carrier Infrastructure) Cc: sip-impleme

Re: [Sip-implementors] Session-level value overriden by media-levelvalue in SDP (RFC 4566)

Hi Nataraju, I agree with you that we should not use "a=sendonly" as well as "c=IN IP4 0.0.0.0" in the same SDP. . This test scenario was provided as part of a third party vendor certification. Hence, the doubt. Let me try to bring out the contradiction in the RFC. (1) Section 5, Pag

Re: [Sip-implementors] Session-level value overriden by media-levelvalue in SDP (RFC 4566)

Comments inline... Regards, Nataraju A B > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Jagan Mohan > Sent: Wednesday, December 12, 2007 11:54 AM > To: SIP list; SIP Implementors > Subject: [Sip-implementors] Session-level value overriden by

[Sip-implementors] Session-level value overriden by media-level value in SDP (RFC 4566)

Hi, For example, a SIP message has the following SDP: v=0 c=IN IP4 0.0.0.0 t=2873397496 2873404696 m=audio 49170 RTP/AVP 0 a=sendonly I would like to know whether a=sendonly or c=IN IP4 0.0.0.0 should take into effect in this particular case. From RFC 4

Re: [Sip-implementors] NOTIFY without SUBSCRIBE

Brett Tate wrote: >> Certainly the motivation for the existing wording was to >> accommodate REFER, and I suppose similar arrangements. > > Yes; and subscriptions created through configuration (section 3.2.2). > > >> NOTIFYs that don't contain a to-tag don't identify an >> expected dialog, so

Re: [Sip-implementors] NOTIFY without SUBSCRIBE

> Certainly the motivation for the existing wording was to > accommodate REFER, and I suppose similar arrangements. Yes; and subscriptions created through configuration (section 3.2.2). > NOTIFYs that don't contain a to-tag don't identify an > expected dialog, so I don't think they are consist

Re: [Sip-implementors] NOTIFY without SUBSCRIBE

Brett Tate wrote: > As far as I know, "unsolicited" NOTIFY violates rfc3265 (however I don't > call notifies related to administrator configured subscriptions > "unsolicited"). And I'm not aware of an RFC allowing NOTIFY to create a > dialog (beyond what can occur because of forking). > > RFC32

Re: [Sip-implementors] NOTIFY without SUBSCRIBE

> On Dec 11, 2007 12:42 PM, Brett Tate <[EMAIL PROTECTED]> wrote: > > > Please confirm my understanding of subscribe for MWI. > NOTIFY should > > > not be sent to a UA unless a SUBSCRIBE has been sent to it. > > > > RFC3265 allows for non-SUBSCRIBE mechanisms to create subscriptions. > > Some v

Re: [Sip-implementors] NOTIFY without SUBSCRIBE

Vikram Chhibber wrote: > On Dec 11, 2007 12:42 PM, Brett Tate <[EMAIL PROTECTED]> wrote: >>> Please confirm my understanding of subscribe for MWI. NOTIFY >>> should not be sent to a UA unless a SUBSCRIBE has been sent to it. >> RFC3265 allows for non-SUBSCRIBE mechanisms to create subscriptions.

Re: [Sip-implementors] NOTIFY without SUBSCRIBE

On Dec 11, 2007 12:42 PM, Brett Tate <[EMAIL PROTECTED]> wrote: > > Please confirm my understanding of subscribe for MWI. NOTIFY > > should not be sent to a UA unless a SUBSCRIBE has been sent to it. > > RFC3265 allows for non-SUBSCRIBE mechanisms to create subscriptions. > Some vendors use the co

Re: [Sip-implementors] NOTIFY without SUBSCRIBE

> Please confirm my understanding of subscribe for MWI. NOTIFY > should not be sent to a UA unless a SUBSCRIBE has been sent to it. RFC3265 allows for non-SUBSCRIBE mechanisms to create subscriptions. Some vendors use the concept to allow subscriptions to be created for their users (automaticall

Re: [Sip-implementors] NOTIFY without SUBSCRIBE

This is non-standard unsolicited NOTIFY. You may accepts it for "message-summary" Event as many Voice Mail Servers are sending this unsolicited NOTIFY request. ~Vikram www.veraznetworks.com On Dec 11, 2007 10:39 AM, Jack W. Lix <[EMAIL PROTECTED]> wrote: > Hi all, > > > > Please confirm my unders

[Sip-implementors] NOTIFY without SUBSCRIBE

Hi all, Please confirm my understanding of subscribe for MWI. NOTIFY should not be sent to a UA unless a SUBSCRIBE has been sent to it. I'm doubting my understanding because I just got an asterisk server running and it immediately sends a NOTIFY after I REGISTER with it. The NOTIFY does n

Re: [Sip-implementors] Different transport in same call.

From: "Jitendra Singh Bhadoriya" <[EMAIL PROTECTED]> Can anyone please tell me if a UAS receives the INITIAL INVITE on UDP and after that subsequent ACK on TCP then will it be able to process that ACK. I believe Brett Tate explained the rules for how an ACK should be sent. But for ge

[Sip-implementors] sip phone suffers one-way speech during PSTN call

Hi all, I met a problem that sip-phone experienced one-way-speech on the direction to sip-phone in both sipphone-PSTN and PSTN-sipphone call. I need you guys help me to confirm the hypothesis: I got the trace files, Sip Phone-PSTN: There are some SIP header and body fields that I haven't seen b

Re: [Sip-implementors] [Sip] To-tag in CANCEL response

> 1) All the 200 OK for the CANCEL responses do not contain > any To-tags. But according to RFC3261 section 16.10, a > stateful proxy should act as a UAS, which then require > the response to have a To-tag. Isn't it? This is an error in RFC 3665. All final responses must have to-tag. > 2) Assume

Re: [Sip-implementors] [Sip] To-tag in CANCEL response

Hi Tonny, Please post such queries to sip-implementors at lists.cs.columbia.edu ! Please see inline... *** This e-mail and attachments contain confidenti