- Original Message -
From: Richard
Hi all,
Suppose caller A wants to initiate a video call with B. He sends an
INVITE to B and B accepts the call and then sends back 200 OK with SDP.
According to RFC 3264, practically caller B will send the audio and
video RTP packet to caller
Hi Richard,
Why does A require the 200 OK to be able to decode the packets? The 200
OK contains information about what B wishes to receive. A should already
have opened its decoders as soon as it send the INVITE outwards. It
knows the PayloadTypes that B is going to send it. So it can also detect
you could use ICE, to ensure you have connectivity.
Then, by time the ICE checks have completed you will be able to start
sending the video and expect the other end to receive it.
Paul
Richard wrote:
> Hi all,
>
> Suppose caller A wants to initiate a video call with B. He sends an
Richard wrote:
> Hi all,
>
> Suppose caller A wants to initiate a video call with B. He sends an
> INVITE to B and B accepts the call and then sends back 200 OK with SDP.
> According to RFC 3264, practically caller B will send the audio and
> video RTP packet to caller A immediately. Since
Hi all,
Suppose caller A wants to initiate a video call with B. He sends an
INVITE to B and B accepts the call and then sends back 200 OK with SDP.
According to RFC 3264, practically caller B will send the audio and
video RTP packet to caller A immediately. Since SIP messages and RTP
packe
Virtually every network I know of which uses npdi, rn, and cic, use them as
uri-user params in a SIP URI. (i.e., your first example)
-hadriel
> -Original Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-
> implementors-boun...@lists.cs.columbia.edu] On Behalf
On Mon, 2008-12-15 at 18:06 +0200, Anca Vamanu wrote:
> It is not clear from here what part of the R-URI identifies the target
> and whether parameters should also be used.
You are correct -- none of the RFCs specify rigidly how the request-URI
identifies the "resource" in question. Part of the
Hi,
I am a developer for a RLS server and I have encountered a problem with
the interpretation of target list uri for a Subscription.
I consider the list uri to be the u...@domain part from the R-URI of the
initial Subscribe, but someone reported an inconsistency when the R-URI
also contains a
On Mon, Dec 15, 2008 at 2:12 PM, Victor Pascual Ávila
wrote:
> Hi,
> RFC 4694 describes some parameters in the TEL URI to carry the
> NP-related information. Unfortunately, TEL URIs are not always used in
> this context and E.164-based SIP URIs are used instead. Any experience
> on using parameter
Iñaki Baz Castillo wrote:
> El Viernes, 12 de Diciembre de 2008, Paul Kyzivat escribió:
>> There are a few uses that I know of:
>>
>> 1) to forcibly *unregister* a device. For instance, you have a device
>> registered from work, and then you go home without turning it off.
>> From another
El Lunes, 15 de Diciembre de 2008, chandan kumar escribió:
> Hi ,
>
> Iam testing IP phone which supports video & Audio.Iam facing an issue like
> .Iam testing on 2 DSL lines . So End users are on different NAT's. I have
> registered both the users to Public SIP servers( freel available servers
Hi,
RFC 4694 describes some parameters in the TEL URI to carry the
NP-related information. Unfortunately, TEL URIs are not always used in
this context and E.164-based SIP URIs are used instead. Any experience
on using parameters like rn, rn-context, npdi, cic or cic-context in
SIP URIs?
Thanks in
Hi ,
Iam testing IP phone which supports video & Audio.Iam facing an issue like
.Iam testing on 2 DSL lines . So End users are on different NAT's. I have
registered both the users to Public SIP servers( freel available servers for IP
calls , using SIPgate).Registration happens.I made call ,ca
El Viernes, 12 de Diciembre de 2008, Paul Kyzivat escribió:
> There are a few uses that I know of:
>
> 1) to forcibly *unregister* a device. For instance, you have a device
> registered from work, and then you go home without turning it off.
> From another suitable device at home you can un
14 matches
Mail list logo
