Hi fellows,
Sorry Roman
Somebody know what means the following messages---> Message body is too big:
232253 bytes with a limit of 150 KB
Your mail to 'discussion' with the subject
RE: SIP to SS7 Calling Number Information
Is being held until the list moderator can review it for approval.
The reason it is being held:
Message body is too big: 232253 bytes with a limit of 150 KB
Either the message will get posted to the list, or you will receive
notification of the moderator's decision. If you would like to cancel this
posting, please visit the following URL:
http://sipforum.org/mailman/confirm/discussion/38d5c659ef84eeac6e206ce83a18c5a7db82dd97
Guillermo Zuniga
Especialista de Soporte Técnico
Gerencia de Soporte Técnico
Cable & Wireless Panama, S.A.
Tel: +507 263-6671
Fax: +507 265-3295
Cel: +507 6670-0481
Email: guillermo.zun...@cwpanama.com
-----Mensaje original-----
De: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] En nombre de Roman
Shpount
Enviado el: Tuesday, July 12, 2016 12:19 PM
Para: Dale R. Worley
CC: Sip-implementors@lists.cs.columbia.edu
Asunto: Re: [Sip-implementors] Handoff
On Tue, Jul 12, 2016 at 11:58 AM, Dale R. Worley <wor...@ariadne.com> wrote:
> Paul Kyzivat <pkyzi...@alum.mit.edu> writes:
> > ISTM that there is dubious likelihood of success of this is
> > attempted after the previous connection has already failed.
> > Make-before-break is safer if you can get some advanced warning. But
> > make-before-break has its own implications on how you do this so
> > that it doesn't become break-while-trying-to-make.
>
> At least in theory, you can make-after-break, since INVITE-Replaces
> can snatch a call from an endpoint that is no longer reachable. (The
> remote endpoint resends BYE many times, and then drops the dialog, but
> the user interface is moved to the new dialog immediately.)
>
> As someone else noted, the important thing is to detect the break
> quickly enough that the call can be reestablished before session
> timers expire.
>
> You actually need to recover the connection before the transaction
> times
out in order to make sure that SIP Session timer does not close the dialog.
Session timer connectivity check and connection failure can occur at any time
relative to each other. Because of this, connection can fail at the time of
session timer connection check, no matter how often you check the connectivity.
The only way to preserve the dialog is to reestablish the network connection
while connectivity check is still running. This is, by the way, one more reason
why we use UDP timers for TCP based messages -- it gives the client time to
detect the connection failure and recover the connection.
_____________
Roman Shpount
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
El contenido de este correo es confidencial y puede ser objeto de acciones
legales. Es dirigido solo para el o los destinatarios(s) nombrados
anteriormente. Si no es mencionado como destinatario, no debe leer, copiar,
revelar, reenviar o utilizar el contenido de este mensaje. Si ha recibido este
correo por error, por favor notifique al remitente y proceda a borrar el
mensaje y archivos adjuntos sin conservar copias.
The information contained in this e-mail is confidential and may also be
subject to legal privilege. It is intended only for the recipient(s) named
above. If you are not named as a recipient, you must not read, copy, disclose,
forward or otherwise use the information contained in this email. If you have
received this e-mail in error, please notify the sender immediately by reply
e-mail and delete the message and any attachments without retaining any copies.
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
