Hi everyone,
I was looking at:
http://tools.ietf.org/html/rfc4975#section-11.4
Could someone explain to me why such a scheme is required? This example
(though contrived) uses 2 MSRP chunks and a CPIM body just to transmit
14 characters.
The reason I'm asking is because there are a number of RCS
As others have noted, session timer can be used for this, and OPTIONS is
a bad choice.
But note that session timer is primarily for the benefit of
dialog-stateful *proxies*, because they have no way to test the dialog
on their own. All session timer does is schedule a time when the dialog
shou
26 jun 2013 kl. 14:32 skrev Brett Tate :
> Hi,
>
> If they are use OPTIONS to determine call/subscription/dialog state...
>
> Does anyone know what response they are expecting to receive when there is no
> dialog usage?
>
> Does anyone know the RFC snippet indicating what should be sent and h
Hi,
If they are use OPTIONS to determine call/subscription/dialog state...
Does anyone know what response they are expecting to receive when there is no
dialog usage?
Does anyone know the RFC snippet indicating what should be sent and how the UAC
should act upon receiving the response?
Thanks
Brett
I agree that OPTIONS is not a recommended way, however I believe that it is
still being used by many end points (may be due to ease of implementation).
Regards
Tarun Gupta
Aricent
-Original Message-
From: Brett Tate [mailto:br...@broadsoft.com]
Sent: Wednesday, June 26, 2013 4:26
The application should be capable enough to handle this scenario. I am not
sure if I have understood the question clearly.
Are we hinting that we have a call dialog established and media is getting
transmitted for a long time approx. 1 hour and we don't
want the established SIP call session to be t
I do not recommend attempting to use OPTIONS to determine call/dialog state.
RFC 3261 is ambiguous concerning if a 481 should ever be sent for OPTIONS.
Similarly RFC 5057 clarifies that OPTIONS is not part of dialog usage; thus a
481 has no impact/meaning. There isn't another OPTIONS response
See RFC 4028.
> -Original Message-
> From: ikuzar RABE [mailto:ikuzar9...@gmail.com]
> Sent: Wednesday, June 26, 2013 5:27 AM
> To: sip-implementors@lists.cs.columbia.edu
> Subject: [Sip-implementors] SIP messages exchange to maintain a session
>
> Hi all,
>
> I'd like to know if there a
Hi
For keep alive, you can use OPTIONS or Session Timers (see RFC 4028) for
details on usage.
Regards
Tarun Gupta
Aricent
-Original Message-
From: ikuzar RABE [mailto:ikuzar9...@gmail.com]
Sent: Wednesday, June 26, 2013 2:57 PM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-i
Hi all,
I'd like to know if there are SIP messages exchange to maintain the session
between two UA (message such as "Hello, I'am still here" / "Hello, I'am
still here too" while RTP conversation is established and lasts a longtime.
The context:
I have to differentiate an INVITE with a BYE which a
10 matches
Mail list logo
