[Sip-implementors] Enconding of Callee Capabilities Priority feature-tag as string och numeric bnf-construct

the summary description which says: "A value of X meanspriority X and higher"...which would make the ">=;<=;=" operators redundant. At the same time, RFC3841 indicates that the matching process: The matching rules in RFC 2533 only require an implementation to

Re: [Sip-implementors] Transport Selection dependent on message size and NAPTR priorities (pitting rfc3261 vs rfc3263)

hen the logic of falling back to UDP when tcp fails, is completely useless? This is another reason why I feel that the transport-rule in 18.1.1 should *override* whatever NAPTR indicates, because if you cant, the fallback requirement is less usefull. Regards Taisto Qvist -- __

Re: [Sip-implementors] Transport Selection dependent on message size and NAPTR priorities (pitting rfc3261 vs rfc3263)

I am mainly looking to ensure that my feeling that its better to priorities your NAPTRs to know what *should* be the default is not way of the target, and that there are some real scenarios where same-prio NAPTRs are a GOOD idea. Thanks for your reply so far, and I hope others might c

[Sip-implementors] Transport Selection dependent on message size and NAPTR priorities (pitting rfc3261 vs rfc3263)

transport protocols? Best Regards Taisto Qvist (S)IP Teacher and Developer ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Multiple 200 OK responses processing

any proxy towards the UAS:es, since they are not sent using the old INVITE transaction. If you do not, you will recieve 2xx retransmissions for T1x64 seconds for each confirmed dialog created. Regards Taisto Qvist IP-Solutions.se - Original Message - From: "VARUN BHATIA" To: &q

[Sip-implementors] Restarting Timer F/B on rfc3263 defined failure

restart these Timers, at least not for nonInvite, I just though I would see if I could get some confirmation on this interpretation. I'd be very interested, and thankful for whatever feedback you folks can provide. Thanks in advance Regards Taisto Qvist IP-Solutions AB ___

Re: [Sip-implementors] Clarifying RFC3261/3 regarding 503's and retry-after

to 3261/3 fetch the next RR and retry? I'd be very interessted, and thankful for whatever feedback you folks can provide. Thanks in advanced Regards Taisto Qvist IP-Solutions AB ___ Sip-implementors mailing list Sip-implementors@lists.cs.c

[Sip-implementors] FW: Clarifying RFC3261/3 regarding txn-timers

mer F as always. So, when reading rfc4320/21 where they clearly *imply* that you should NOT restart these Timers, I just though I would see if I could get some confirmation on this interpretation. I'd be very interessted, and thankful for whatever feedback you folks can provide. Than

[Sip-implementors] Clarifying RFC3261/3 regarding route-preprocessing

c, but the term "indicates this proxy", is a bit to vague for my taste, so I wouldnt mind hearing your views. I'd be very interessted, and thankful for whatever feedback you folks can provide. Thanks in advanced Regards Taisto Qvist IP-Solutions AB __

[Sip-implementors] Clarifying RFC3261/3 regarding txn-timers, route-preprocessing, 503's and SHOULD use ; transport=PROTO

Timer F as always. So, when reading rfc4320/21 where they clearly *imply* that you should NOT restart these Timers, I just though I would see if I could get some confirmation on this interpretation. I'd be very interessted, and thankful for whatever feedback you folks can provide.