add support for receiving UPDATE requests
juha-h opened this issue · comments
I'm returning to the old issue of adding support for receiving UPDATE requests. I read RFC 3311 and here is my summary on what would need to be done:
-
add UPDATE in Allow header of INVITE and 2xx response (in baresip)
-
if UPDATE is received and dialog (early or confirmed) has not been
established yet, or, if dialog has been established but reply has not
yet been received to in-dialog INVITE, 491 Request Pending response is
generated -
if UPDATE is received before response is sent to earlier UPDATE or
INVITE request, 500 response is generated to the UPDATE with Retry-After
between 0 and 10 sec -
when UPDATE is received and the previous two conditions don't exist:
-
UAS must update session parameters and generate 2xx response or, if
session parameters are not acceptable, generate 488 response -
UAS must update remote target based on Contact header of UPDATE
-
The above does not look too complicated, but I'm not any re expert. Can it happen that processing of received requests from the same peer overlap or are they handled sequentially?
hi @juha-h
SIP UPDATE is already on the Roadmap:
https://github.com/creytiv/re/wiki/Roadmap
it is very unlikely that we are able to implement this in the near future.
the description looks okay to me, but I do not have in-depth knowledge about
this method. I think implementing a prototype and then testing it will reveal
what is working and not.
You are welcome to try to implement it :)
The question regarding re was:
Can it happen that processing of received requests from the same peer overlap or are they handled sequentially?
If they are processed sequentially, implementing of UPDATE becomes simpler.
since we are not working on this at the moment, I will close this one for now