From: sip-implementors-boun...@lists.cs.columbia.edu
[sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Nitin Kapoor
[nitinkapo...@gmail.com]
I am facing the problem with one of my client. I can see we are getting the
2 codecs in SDP(G.711 & G.
2010/3/20 Schwarz Albrecht :
> It's amazing that such a fundamental session configuration topic is not
> really well specified (explicitly, detailed, unambiguous) in RFCs 3261 &
> 3264. Just wondering ...
I agree. When such kind of issues occur it means that interoperability
is difficult as diff
2010/3/19 Paul Kyzivat :
> Actually, Brett gave the best answer.
>
> The lack of response to OPTIONS should not have caused a presumption that
> the dialog, or the invite dialog usage, has failed. Lacking some other
> failure, the RTP should have continued to flow and the call should have
> stayed
Actually, Brett gave the best answer.
The lack of response to OPTIONS should not have caused a presumption
that the dialog, or the invite dialog usage, has failed. Lacking some
other failure, the RTP should have continued to flow and the call should
have stayed up.
Once the RTP stopped flowing
2010/3/19 WORLEY, DALE R (DALE) :
> The basic answer to your question is "yes". In general, in any dialog or
> usage, if a UA decides that it is terminated, for any reason than a message
> from the remote UA that states that the dialog/usage is termianted, the UA
> should send an explicit termi
From: sip-implementors-boun...@lists.cs.columbia.edu
[sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Premalatha Kuppan
[premalathakup...@gmail.com]
Thanks for the valuable comments.
Then during outgoing call, how can both devices participat
The basic answer to your question is "yes". In general, in any dialog or
usage, if a UA decides that it is terminated, for any reason than a message
from the remote UA that states that the dialog/usage is termianted, the UA
should send an explicit termiantion message.
In this case, if a UA rec
> Is the below TEL URI is a Global Number?
No. As indicated within the snippets you provided; per RFC 3966, it is a
malformed TEL URI.
> -
> tel:3036619110;cic=+1234
> -
> I mean in the absence of leading '+' and ;phone-context param ,
> Should we consider Global CIC also?
>
Hi All,
Is the below TEL URI is a Global Number?
-
tel:3036619110;cic=+1234
-
I mean in the absence of leading '+' and ;phone-context param ,
Should we consider Global CIC also?
As per the RFC 3966
-
Globally unique numbers are identified by the leading "+"
char
2010/3/19 Paul Kyzivat :
> Iñaki,
>
> Note that specifying a=recvonly gives a receive the video without sending
> any. But in that case you are still expected to send rtcp.
> If you want to avoid that too, then you should specify c=0.0.0.0.
Thanks for clarification. However I don't see the problem
> 2010/3/19 Brett Tate :
> >> But in any case, no specification states that, upon an in-dialog
> >> OPTIONS timeout, the UA should terminate the RTP without sending
> >> a BYE. Am I right?
> >
> > Correct. However if I recall correctly, rfc3261 often only indicates
> SHOULD send BYE instead of MUS
KUMARAVEL ANAND-MWCH34 wrote:
>
> Hanifa,
> As per RFC 5627,section 3.2, all of the temporary GRUUs learned
> from REGISTER responses of a contact remain valid as long a contact with
> that instance ID remains registered and the UA doesn't change the
> Call-ID in its REGISTER request comp
Iñaki,
Note that specifying a=recvonly gives a receive the video without
sending any. But in that case you are still expected to send rtcp.
If you want to avoid that too, then you should specify c=0.0.0.0.
Thanks,
Paul
Iñaki Baz Castillo wrote:
> 2010/3/19 :
>> Hi,
>>
>> Yes, B
2010/3/19 Brett Tate :
>> But in any case, no specification states that, upon an in-dialog
>> OPTIONS timeout, the UA should terminate the RTP without sending
>> a BYE. Am I right?
>
> Correct. However if I recall correctly, rfc3261 often only indicates SHOULD
> send BYE instead of MUST send BYE
> > The following is a link to one of the threads:
> >
> > http://www.ietf.org/mail-archive/web/sipcore/current/msg02020.html
>
> Thanks, but that thread doesn't handle the case in which
> an in-dialog OPTIONS fails due to timeout (no response).
I agree; however it reflects some of the ambiguiti
2010/3/19 Brett Tate :
> For what it worth, sipcore has been discussing OPTIONS lately concerning
> issues when used in-dialog and outside of dialog. OPTIONS will be discussed
> at the IETF meeting.
>
> The following is a link to one of the threads:
>
> http://www.ietf.org/mail-archive/web/sipco
For what it worth, sipcore has been discussing OPTIONS lately concerning issues
when used in-dialog and outside of dialog. OPTIONS will be discussed at the
IETF meeting.
The following is a link to one of the threads:
http://www.ietf.org/mail-archive/web/sipcore/current/msg02020.html
Concernin
2010/3/19 Saúl Ibarra :
> Hi!
>
> I'm currently working on implementing
> http://tools.ietf.org/html/draft-lee-sip-dns-sd-uri-03 in sipsimple
> SDK and I'd love to test interoperability with other SIP clients in
> this matter.
>
> Is there any SIP client (open or closed source) which implements thi
Hi!
I'm currently working on implementing
http://tools.ietf.org/html/draft-lee-sip-dns-sd-uri-03 in sipsimple
SDK and I'd love to test interoperability with other SIP clients in
this matter.
Is there any SIP client (open or closed source) which implements this
draft out there?
Thanks in advance
2010/3/19 Avasarala Ranjit-A20990 :
> Its not fully unfeasible. Its possible and there are solutions where it is
> done. Check the 3GPP spec: TS 23.893 (section 5.2)
I really promised myself not to waste my time reading 3GPP/OMA/RCS
documents anymore :)
Closed solutions for closed networks.
--
Hi Iñaki,
On Fri, Mar 19, 2010 at 1:37 PM, Iñaki Baz Castillo wrote:
> Hi, let me redefine a question I already did:
>
>
> - A client initiates a SIP UDP call with a server. The call is
> correctly established.
>
> - After the INVITE transaction the client sends an in-dialog OPTIONS
> to check th
Hi
Its not fully unfeasible. Its possible and there are solutions where it is
done. Check the 3GPP spec: TS 23.893 (section 5.2)
Regards
Ranjit
-Original Message-
From: Iñaki Baz Castillo [mailto:i...@aliax.net]
Sent: Friday, March 19, 2010 6:10 PM
To: Avasarala Ranjit-A20990
Cc: Pre
> -Original Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-
> implementors-boun...@lists.cs.columbia.edu] On Behalf Of Premalatha
> Kuppan
>
> Is there any other approach, please suggest ?
Maybe you could treat the call normally and answer it on your mobile p
2010/3/19 Avasarala Ranjit-A20990 :
> With Asterisk u may not be able to, because Asterisk is not a SIP Proxy or
> B2BUA. It's a IP-PBX.
Sure, Asterisk will not let you answering a call from two endpoints at
the same time.
Again, what you are trying to achieve is so exotic that it's, in fact,
fu
Hi, let me redefine a question I already did:
- A client initiates a SIP UDP call with a server. The call is
correctly established.
- After the INVITE transaction the client sends an in-dialog OPTIONS
to check the dialog status.
- Due to a SIP stack bug, the server ignores the in-dialog OPTIONS
Hi
I do not think just by using B2BUA u could achive the scenario being discussed.
There needs to be a rule that says where the audio needs to be routed to and
where the video needs to be routed to. So here the incoming media needs to be
first split into audio and video streams, calls need to b
Yes. I agree. I should achieve using B2BUA.
Actaully i tried a scenario, making call to both devices. Here i used
asterisk server to achieve this.
So, thought if i could make both device same URI at user A and make a call.
Similar to our PSTN, two parallel lines.
Is there any other approach, ple
If the forking proxy knows the service that it is attempting to perform (i.e.
group video only device with an audio device), it wouldn't send the immediate
CANCEL even if rfc3261 or another RFC says it must or should. However there is
little reason to discuss since the service is typically done
2010/3/19 Brett Tate :
> It is standard service related forking. The issue is that the caller likely
> won't keep both calls up after answer.
The problem before it is the fact that when UAS-1 replies 200 the
forking proxy would inmediately cancel the second one, so just in the
exotic case both U
GRUU has nothing to do with this scenario and neither does SIP has a
mechanism to achieve it straight away.
You can use a B2BUA to achieve it.
B2BUA can fork the call from B to both the devices of A (in your case
mobile&Laptop) with different SDP,one with audio(mobile) and other with
video(laptop
It is standard service related forking. The issue is that the caller likely
won't keep both calls up after answer. And if the caller is willing to
conference them somehow, the caller might not like the concept of one of the
reached parties only supporting audio while another only supports vide
2010/3/19 Premalatha Kuppan :
> Say for example, User B calls User A. @ User A i have GRUU support.
>
> Here, i want both my devices @ User A to be alerted and should participate
> in a call.
>
> How can do this ?
>
> I assume, using GRUU i can reach both my end devices. Correct me if iam
> wrong.
Say for example, User B calls User A. @ User A i have GRUU support.
Here, i want both my devices @ User A to be alerted and should participate
in a call.
How can do this ?
I assume, using GRUU i can reach both my end devices. Correct me if iam
wrong.
On Fri, Mar 19, 2010 at 5:23 PM, Brett Tate
What you are describing requires a B2BUA and is supported by some vendors.
GRUU has no direct relevance upon the service.
> -Original Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-
> implementors-boun...@lists.cs.columbia.edu] On Behalf Of Premalatha
> Kuppa
2010/3/19 Premalatha Kuppan :
> This is my scenario:
>
> I have a sip client in my Mobile phone, but no video support. For a video
> chat, i want to use my mobile for audio and video should be displayed in
> laptop.
>
> I was curious whether using GRUU concept, can i make both the devices to
> part
This is my scenario:
I have a sip client in my Mobile phone, but no video support. For a video
chat, i want to use my mobile for audio and video should be displayed in
laptop.
I was curious whether using GRUU concept, can i make both the devices to
participate in a call. Such that, my Mobile phon
2010/3/19 Premalatha Kuppan :
> Here my main intention is to deliver audio to one device and video to other
> device. Is it possible ?
Hyper-exotic scenario that will never work in the real world.
"Theorically" such behavior is possible if both UAS's reply 200 at the
same time (so the forking pro
2010/3/19 :
> Hi,
>
> Yes, Bob can accept, but to decode Video Bob system must be capable of
> decoding the codec offered in Video SDP.
This is common. A softphone is usually able to render an incoming
video stream, but a webcam is required to sent video :)
> He can answer with Send Recive for
Hanifa,
As per RFC 5627,section 3.2, all of the temporary GRUUs learned
from REGISTER responses of a contact remain valid as long a contact with
that instance ID remains registered and the UA doesn't change the
Call-ID in its REGISTER request compared to previous ones for the same
reg-id.
the port number is set to zero to alert Alice that he doesn't want to receive
any video stream (use case 1).
if he wants to receive the stream but want to alert Alice that he can't send
video stream then add "a=recvonly" attribute (use case 2).
--- En date de : Ven 19.3.10, Iñaki Baz Castillo a
Hi,
In GRUU, for every REGISTER, the Registrar gives a different temp-gruu
value. i.e. even for each
refresh, a temp gruu is given. Registrar guarantees that all temp gruu's are
valid till the user
deregisters or change-in-callid value.
My question is that whether the first temp-gru
41 matches
Mail list logo
