Gary Cote | 1 Mar 01:36 2007
Picon

Re: New Transaction

Mandeep,

I think you might've gotten confused somewhere along the way. The
NOTIFY cannot be considered part of the same transaction. It is a new
request and all new requests are sent within their own transaction
(excepting the very special case of ACKs to non-2xx responses).

Furthermore, the UA on the left side of the screen is expecting a
response. There's no way that it can associate a new incoming request
to an outstanding client transaction.

You mention from/to tags ... is it possible that you're confusing the
concepts of "transaction" and "dialog?"

--

-- 
Gary Cote
www.awardsolutions.com
Paul Kyzivat | 1 Mar 01:40 2007
Picon

Re: Unsolicited NOTIFY

Dale,

I'm in an awkward position here because I know there is such usage by 
products from a company that I have some familiarity with.

Dale.Worley <at> comcast.net wrote:
>    From: Paul Kyzivat <pkyzivat <at> cisco.com>
> 
>    If the NOTIFY arrives out of dialog then I don't think 481 is a suitable 
>    response, unless we also want to overload it further to mean "this 
>    should have been in a dialog".
> 
> Well, I take 481 to mean "This request presupposes the existence of a
> dialog, dialog usage, subscription, or whatnot (as appropriate for the
> request), but the requited whatnot does not exist, and so I cannot
> process the request."  That seems to be the common meaning among its
> various uses.

Well, we are talking hypotheticals here, since the usage is invalid.

The request is sent outside of a dialog, and, afaik it doesn't intend to 
establish one either. So the sender isn't presupposing the existence of 
one. In fact, my understanding is that *not* maintaining any dialog 
state is an express goal of using an unsolicited notify.

> If the recipient is *expecting* to see the NOTIFY, I don't see it as a
> problem that the two UAs would treat the NOTIFY as establishing a
> dialog (presumably within which later NOTIFYs in the subscription
> would arrive), even if that's not strictly within the current
> standards.
(Continue reading)

Satyendra Tiwari | 1 Mar 05:00 2007

Re: Music on Hold

Hello,

Link for flow with the diagram,

http://www.tech-invite.com/Ti-sip-service-3.html

There are three differnet approaches to send hold signal in Re-Invite(SDP):

1. Send a re-Invite with "0.0.0.0" as the IP address in the sdp data
2. Send a re-Invite with the parameter a=sendonly set in the sdp data
  caller a=sendonly, callee a=recvonly(response).This is the    currently recommended way of signaling hold.
3.Send a re-Invite with the parameter a=inactive set in the sdp data
  caller a=inactive, callee a=inactive.(response)

Thanks and Regards
Satyendra Tiwari
Alcatel-Lucent

On Wed, 28 Feb 2007 varun wrote :
>Hi,
>Can somebody explain me the music on hold call flow
>with the various SDP options?
>
>Thanks
>Naveen
>
>
>
>____________________________________________________________________________________
>We won't tell. Get more on shows you hate to love
(Continue reading)

Sanjay Sinha (sanjsinh | 1 Mar 05:46 2007
Picon

Re: rfc3261: why lr excluded for redirect andregister Contact

Pl. look at draft-rosenberg-sip-ua-loose-route-00.txt, it is no longer
prohibited in Register also.

>-----Original Message-----
>From: sip-implementors-bounces <at> cs.columbia.edu 
>[mailto:sip-implementors-bounces <at> cs.columbia.edu] On Behalf Of 
>Brett Tate
>Sent: Wednesday, February 28, 2007 2:21 PM
>To: sip-implementors <at> cs.columbia.edu
>Subject: [Sip-implementors] rfc3261: why lr excluded for 
>redirect andregister Contact
>
>Greetings,
>
>RFC 3261 section 19.1.2 table 1 explicitly allows lr in dialog 
>Contact sip-uri; but it indicates differently for register and 
>redirect Contact.
>If anyone knows why such a distinction was explicitly 
>documented, please explain.  I assume that it was to avoid 
>potential confusion concerning parameters like expires and q; 
>however I thought that I'd ask.
>
>Thanks,
>Brett
>
>_______________________________________________
>Sip-implementors mailing list
>Sip-implementors <at> cs.columbia.edu
>https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
(Continue reading)

Abu Muttalib | 1 Mar 12:28 2007

What happens to the ongoing call

Hi,

Thank you all.

So I conclude that this behavior on the Part of UA (SIP phone) is illegal.

Call won't break.

RFC as such doesn't say anything about this scenario. This is implementation
defined behavior.

Regards,
Abu.

1...............

UA is responsible for refreshing the bindings it has established, so the
behavior you described is illegal.
Assume the behavior of your UA is allowed just for the sake of
discussion,when a dialog established, all the following requests are in
dialog,  should be constructed according to rfc 3261, 12.2, request-uri is
built from remote target and route set, so the binding it registered
previous is not needed.

2...........

The call stays...

The role of the registrar is to maintain bindings of user agents to 
their address of record.  Whether the registrar and the proxy resides in 
(Continue reading)

Satyendra Tiwari | 1 Mar 13:24 2007

Max-Forward Header

Hello,

Is Max-Forward header mandatory in SIP responces?
If optional then why?

Thanks And Regards,
Satyendra Tiwari
Alcatel-Lucent
Chaney, Charles (SNL US | 1 Mar 15:34 2007
Picon

Multiple contact bindings - registration response

Hi,

I have a question regarding contact headers returned in the registration
response where more than one contact binding exists. Should a new
registration or refresh "touch" other existing contact bindings for the
AoR? The question is specific to the expires value reported for each
contact binding. I understand that if the registrar accepts the
registration request the expires value reflects the accepted expiration
time for that contact binding, but some questions have been raised about
the expires value reported for the other contact binding. Should the
other contact binding reflect the remaining (time-to-live) expiration
value or be updated to reflect the new registration (or refresh), i.e.,
all are reported with the same expires value. I cannot point to any
definitive requirement in RFC3261.

Thanks

Rick Whitesel (rwhitese | 1 Mar 16:06 2007
Picon

RFC 3264 - Placing SDP on hold - How hold differs from initial exchange?

Hi:
    From RFC 3264:

8.4 Putting a Unicast Media Stream on Hold

   If a party in a call wants to put the other party "on hold", i.e.,
   request that it temporarily stops sending one or more unicast media
   streams, a party offers the other an updated SDP.

   If the stream to be placed on hold was previously a sendrecv media
   stream, it is placed on hold by marking it as sendonly.  If the
   stream to be placed on hold was previously a recvonly media stream,
   it is placed on hold by marking it inactive.

   This means that a stream is placed "on hold" separately in each
   direction.  Each stream is placed "on hold" independently.  The
   recipient of an offer for a stream on-hold SHOULD NOT automatically
   return an answer with the corresponding stream on hold.  An SDP with
   all streams "on hold" is referred to as held SDP.

      Certain third party call control scenarios do not work when an
      answerer responds to held SDP with held SDP.

How does this behavior differ from section 6, initial exchange?

I have seen an softphone that does no seem to understand the media
direction attribute. Is it even possible for a device that does
understand and use media direction to interoperate correctly with one
that does not?

(Continue reading)

Paul Kyzivat | 1 Mar 16:16 2007
Picon

Re: Multiple contact bindings - registration response


Chaney, Charles (SNL US) wrote:
> Hi,
>  
> I have a question regarding contact headers returned in the registration
> response where more than one contact binding exists. Should a new
> registration or refresh "touch" other existing contact bindings for the
> AoR? The question is specific to the expires value reported for each
> contact binding. I understand that if the registrar accepts the
> registration request the expires value reflects the accepted expiration
> time for that contact binding, but some questions have been raised about
> the expires value reported for the other contact binding. Should the
> other contact binding reflect the remaining (time-to-live) expiration
> value or be updated to reflect the new registration (or refresh), i.e.,
> all are reported with the same expires value. I cannot point to any
> definitive requirement in RFC3261.

It always seemed clear to me, even if only implicit.

Each registered contact has its own expiration time that counts down. In 
a new register request, only the contacts mentioned in the request are 
updated - the others continue counting down their existing expiration time.

There is no other way that makes sense if you assume there are two 
separate UAs each registering their own contact to a common AOR.

	Paul
Paul Kyzivat | 1 Mar 16:35 2007
Picon

Re: RFC 3264 - Placing SDP on hold - How hold differs from initial exchange?


Rick Whitesel (rwhitese) wrote:

> I have seen an softphone that does no seem to understand the media
> direction attribute. Is it even possible for a device that does
> understand and use media direction to interoperate correctly with one
> that does not?

Yes, if the smart one has fallback procedures.

If you offer sendonly, then the answer from a compliant peer should have 
recvonly or inactive. If it has neither, then you can presume that it 
doesn't understand these attributes. In that case, a reasonable fallback 
is to the 2543 procedure of sending an offer with c=0.0.0.0.

	Paul

Gmane