2010/9/22 R M :
> pLs take me off of you list
Fail. You must do it. Inspect the headers of any mail in this maillist.
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implemento
Inline
On 9/22/2010 7:18 AM, abhishek chattopadhyay wrote:
> Hi Implementors,
>
> In 3261 the re-transmission of INVITE is stopped by 1xx responses. So to
> stop the re-trnasmission of 200 OK, ACK is sent.
> (Albait it would be worth considering that ACK is used for a lot of other
> purposes.)
>
>
goutam,
This situation is discussed in section 5.3 of:
http://www.ietf.org/id/draft-ietf-sipping-sip-offeranswer-13.txt
More inline
On 9/22/2010 5:45 AM, goutam kumar wrote:
> Hi,
>
> I'm trying to implement a VOIP call between two endpoints. I'm in a doubt.
>
> Say Alice and Bob are in a call.
pLs take me off of you list
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Hi Abhishek,
Can you elaborate more for three way handshakes and which part of three
way handshakes you think is not required?
100 Trying can be generated even for Re-INVITE if the processing of the
same is going to take more than 200ms. I don't think there is any such
restriction in RFC for this
Thanks Frank,
But what is so special about the invite and re-invite. Why not any other
method in the protocol has this fecility?
Abhishek.
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Frank
On 2010/09/22 13:18, abhishek chattopadhyay wrote:
> Hi Implementors,
>
> In 3261 the re-transmission of INVITE is stopped by 1xx responses. So to
> stop the re-trnasmission of 200 OK, ACK is sent.
> (Albait it would be worth considering that ACK is used for a lot of other
> purposes.)
>
> Further
Hi Implementors,
In 3261 the re-transmission of INVITE is stopped by 1xx responses. So to
stop the re-trnasmission of 200 OK, ACK is sent.
(Albait it would be worth considering that ACK is used for a lot of other
purposes.)
Further form 3261 only, it is clear that for other methods the request w
Goutam,
Then I think there is some *wrong implementation* in Alice's phone. If its
off-hold, its understood that one wants to have two-way media.
If Alice is sending sendonly again (pressuming it to be off-hold) then its
wrong.
Please do check with the Alice's phone vendor!
Regards,
Somesh
Hi,
Yes, when Alice takes the call off-hold the INVITE will have "sendrecv" in
it.
On Wed, Sep 22, 2010 at 3:49 PM, Shanbhag, Somesh (NSN - IN/Bangalore) <
somesh.shanb...@nsn.com> wrote:
> Goutam,
>
> Normally the Step-II shall not happen. It could happen, if Bob's phone
> doesn't want to have o
Slight modification as I mentioned "sendrecv" at the at line instead if
"receive-only".
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
Verma Sunil
Sent: Wednesday, September 22, 2010 3:53 PM
To: g
Hi,
As per offer answer RFC for media attribute "send-only" response can be
"receive-only" or "inactive".
The choice is at the application to decide what needs to be done.
>From the call scenario I think response should be "inactive" as BOB has
put Alice on hold and has not yet retrieve the call.
Goutam,
Normally the Step-II shall not happen. It could happen, if Bob's phone doesn't
want to have one way media or RTCP packets - in this case it can make the media
totally inactive.
May be to save some bandwidth :) but there will be SBC's midway of the call
which can detect the idle media an
Hi,
I'm trying to implement a VOIP call between two endpoints. I'm in a doubt.
Say Alice and Bob are in a call. Now,
STEP I
Alice puts Bob on hold. i.e.
INVITE (RTP-sendonly)
Alice -> Bob
200 OK (RTP-recvonly)
<--
14 matches
Mail list logo
