Hi!
I want to know if any one implemented TMMBR flow control support (RFC
5104) ? Any clients available with this support ?
How do you calculate over-head value(if RTP is considered as reference
protocol layer, then can we use 40 bytes by default )?
--
-Ashwin.
_
Hi all,
another question...
If UAS receives BYE on early dialog and answers it with 200OK, does it have
to respond to initial invite with 487 (same as CANCEL was received)?
regards,
Damir
___
Sip-implementors mailing list
Sip-implementors@lists.cs.colum
HI,
Can you please tell does MIRIAL support sending of INFO message? If yes then
how?
--
cheers
sarvpriya
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
This information can be carried in PIDF by means of XCAP or SIP protocol.
Information that is more of a characteristics of a person as per RFC
4479, large in size and does not change with time is most likely to be
updated and distributed using XCAP mechanism. See also RFC 4483. For
example:
>>The u
El Lunes, 11 de Mayo de 2009, Dale Worley escribió:
> Since the intention is to free the phone's user from dealing with the
> call, any "lines" that show on the phone's user interface can be
> released immediately. Of course, the phone software will still have to
> handle the signaling of these ca
On Mon, 2009-05-11 at 23:06 +0200, Iñaki Baz Castillo wrote:
> > In practice, the solution is for the user agent to perform the transfer
> > in the background by doing nothing until the new call leg is answered,
> > and then sending the REFER that completes the transfer. (This has been
> > underst
On Mon, 2009-05-11 at 18:32 +0200, Francisco José Méndez Cirera wrote:
> A question about the CALL-ID.
>
> 1. UAC sends an INVITE request to Redirect Server with CALL-ID: abc.
> 2. Redirect server sends response "300 Multiples Choices".
> 3. UAC makes a pararell search sending three IN
On Mon, 2009-05-11 at 12:38 +0530, Krishna Rao Gurram wrote:
> Hi,
>
> <-- INVITE
> 100 -->
> 180 -->
> 200 OK ->>
> <-- ACK
> <---REFER (with in the dialog same from tag, To tag and the call-id)
>
> can we send the the above REFER?
>
> (if the above REFER is out side dialog it is OK.)
The abov
El Lunes, 11 de Mayo de 2009, Dale Worley escribió:
> On Sat, 2009-05-09 at 10:05 +0530, Vivek Batra wrote:
> > Moreover, does this mean that an Operator initiating Attended Transfer
> > cannot free-up herself since the transfer target is not responding?
> > This would be very taxing in practical w
Hi, in XMPP and other protocols (MSN, Yahoo), when Alice subscribes to the
presence status of Bob, it receives not just the presence status, but more
data like a custom/funny display-name set by Bob ("super-boby·), a photo, some
custom test ("I'm crazy!!!") and so on.
I already know that the xt
On Sat, 2009-05-09 at 10:05 +0530, Vivek Batra wrote:
> Moreover, does this mean that an Operator initiating Attended Transfer
> cannot free-up herself since the transfer target is not responding?
> This would be very taxing in practical world because most of the
> times, the Operator wishes to exe
El 11/05/2009, a las 18:56, "Scott Lawrence"
escribió:
> On Mon, 2009-05-11 at 18:32 +0200, Francisco José Méndez Cirera wrot
> e:
>> A question about the CALL-ID.
>>
>>1. UAC sends an INVITE request to Redirect Server with CALL-ID:
>> abc.
>>2. Redirect server sends response "300
On Mon, 2009-05-11 at 18:32 +0200, Francisco José Méndez Cirera wrote:
> A question about the CALL-ID.
>
> 1. UAC sends an INVITE request to Redirect Server with CALL-ID: abc.
> 2. Redirect server sends response "300 Multiples Choices".
> 3. UAC makes a pararell search sending three IN
A question about the CALL-ID.
1. UAC sends an INVITE request to Redirect Server with CALL-ID: abc.
2. Redirect server sends response "300 Multiples Choices".
3. UAC makes a pararell search sending three INVITES with CALL-ID:
¿abc?.
I dont understand why first INVITE and three last INV
It is an abnormal situation since device indicated a unique branch transaction
ID when it wasn't actually unique. Thus the UAS can basically act however it
wants.
Processing it as a new transaction for the new call is likely best; however
doing so requires a little more intelligence to handle
Sounds okay; however the CANCEL is typically still needed to cancel the INVITE
(when appropriate) since the BYE received on early dialog isn't adequate to
communicate/trigger cancellation of INVITE.
The lack of CANCEL can trigger useless forking by proxy/b2bua upon receiving
INVITE 487 (or othe
Hello,
Don't forget CANCEL is hop by hop while BYE is end to end.
In a BYE, a Reason header, a body, proprietary information, etc can be passed
to the UAS.
Best regards,
Ben.
> -Original Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu
> [mailto:sip-implementors-boun.
Hi All,
Please consider the following scenario
1. A call has been established between two user agents.
2. A mid dialog non-INVITE transaction has been processed.
3. The call is been terminated.
4. A new call is established.
5. Now a new non-INVITE request has been sent within 32 secs with branch
> It is valid to send BYE on early dialog.
> I just can't imagine myself why it is configurable on this B2BUA
> to send BYE on early dialogs when it wants to terminate the call
> (there is no one at incoming side). I don't see the purpose of it.
It is likely best to ask the vendor of the B2BUA s
Hi Inaki,
It is valid to send BYE on early dialog.
I just can't imagine myself why it is configurable on this B2BUA to send BYE
on early dialogs when it wants to terminate the call (there is no one at
incoming side). I don't see the purpose of it.
regards,
Damir
--- On *Mon, 5/11/09, Iñaki Baz C
Hi,
...
>Could you name B2bua who sends BYE in early dialogs ?
Sorry, I prefer not.
regards,
Damir
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
Damir Reic
Sent: Monday, May 11, 2009 4:20 PM
Jesus Rodriguez wrote:
> Is valid to send a BYE (by caller) for early dialogs:
>
> RFC3261, Section 15: "The caller’s UA MAY send a BYE for either
> confirmed or early dialogs, and the callee’s UA MAY send a BYE on
> confirmed dialogs, but MUST NOT send a BYE on early dialogs."
Aha. I was not
2009/5/11 Carol Chang :
> Sales promotion for YUXIN VOIP Phone ,Gateway.Welcome OEM
Dissapear from here, please.
--
Iñaki Baz Castillo
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/li
2009/5/11 Alex Balashov :
>
>
> Damir Reic wrote:
>
>> This is the question I'm asking because I've seen this B2BUA that actually
>> has a configurable option to send BYE or CANCEL on early dialogs and I don't
>> see any reasons for it. If someone does, please explain.
>
> AFAIK, that's not RFC-com
Hello,
> Damir Reic wrote:
>
>> This is the question I'm asking because I've seen this B2BUA that
>> actually
>> has a configurable option to send BYE or CANCEL on early dialogs
>> and I don't
>> see any reasons for it. If someone does, please explain.
>
> AFAIK, that's not RFC-compliant, and,
This is the question I'm asking because I've seen this B2BUA that
actually has a configurable option to send BYE or CANCEL on early
dialogs and I don't see any reasons for it. If someone does, please
explain.
> CANCEL is only solution here. In case, B2BUA receives 200 OK before it
could send CANCEL
Damir Reic wrote:
> This is the question I'm asking because I've seen this B2BUA that actually
> has a configurable option to send BYE or CANCEL on early dialogs and I don't
> see any reasons for it. If someone does, please explain.
AFAIK, that's not RFC-compliant, and, like you said, CANCEL is
Hi all,
a question from B2BUA perspective.
If on incoming side release is started (not necessarily SIP on incoming
side) and on outgoing SIP side we have established several early dialogs (no
confirmed), is there any sense to send BYE for each of these dialogs?
For me it is not. I believe CANCEL
2009/5/11 Rastogi, Vipul (Vipul) :
> (if the above REFER is out side dialog it is OK.)
>> At places I have seen Out Of Dialog REFER also (to support 3rd party
It's is standar (even if most of the phones don't allow initial REFER).
Unfortunately, more dirty solutions (as 3CPP) are used.
--
Iñaki B
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
Krishna Rao Gurram
Sent: Monday, May 11, 2009 12:39 PM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] Can we send REFER i
Hi,
<-- INVITE
100 -->
180 -->
200 OK ->>
<-- ACK
<---REFER (with in the dialog same from tag, To tag and the call-id)
can we send the the above REFER?
(if the above REFER is out side dialog it is OK.)
Regards,
Krishna..
"DISCLAIMER: This message is proprietary to Aricent and is intended solel
31 matches
Mail list logo
